DKIM, SPF & DMARC

Email authentication prevents spoofing and improves deliverability. Three standards work together to prove that an email genuinely comes from who it claims to come from: SPF, DKIM, and DMARC. Understanding how they work helps you make informed decisions about your domain's email security.

What is SPF?

Sender Policy Framework (SPF) is a DNS-based standard that specifies which servers are authorized to send email on behalf of your domain. When a receiving server gets an email claiming to be from yourdomain.com, it checks that domain's SPF DNS record to see if the sending server's IP address is permitted.

An SPF record is a DNS TXT record on your domain. Here is an example that authorizes Postkit's servers:

v=spf1 include:spf.postkit.eu ~all

This record says:

v=spf1 -- This is an SPF record (version 1)
include:spf.postkit.eu -- Allow any IP address listed in Postkit's SPF record
~all -- Soft-fail emails from any other server (mark as suspicious but don't reject)

When a receiving server checks SPF, it resolves the include directive by looking up spf.postkit.eu to get the actual list of authorized IP addresses. If the sending server's IP matches, the SPF check passes.

SPF only checks the "envelope from" address (the server-level sender), not the "header from" that users see. This is why SPF alone is not enough -- DKIM and DMARC complete the picture.

What is DKIM?

DomainKeys Identified Mail (DKIM) uses cryptographic signatures to verify that an email's content has not been tampered with in transit and that it was authorized by the domain owner.

When Postkit sends an email on your behalf, the signing process works like this:

The process relies on a key pair:

Private key -- Stored securely by Postkit's SMTP engine (Postal). Used to generate a cryptographic signature over the email's headers and body. This key never leaves Postkit's infrastructure.
Public key -- Published as a DNS TXT record on your domain. Receiving servers use this to verify the signature.

The DKIM signature is added as a DKIM-Signature header to the email. It covers specific headers (like From, To, Subject) and the message body. If anything changes after signing, the signature verification fails.

A DKIM DNS record looks like this:

postkit._domainkey.yourdomain.com  TXT  "v=DKIM1; k=rsa; p=MIGf..."

postkit._domainkey -- The selector, identifying which key to use (a domain can have multiple DKIM keys)
v=DKIM1 -- DKIM version 1
k=rsa -- Key type (RSA)
p=MIGf... -- The base64-encoded public key

What is DMARC?

Domain-based Message Authentication, Reporting & Conformance (DMARC) ties SPF and DKIM together and tells receiving servers what to do when authentication fails. It also provides a reporting mechanism so domain owners can monitor authentication results.

A DMARC record is a DNS TXT record at _dmarc.yourdomain.com:

v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com

v=DMARC1 -- DMARC version 1
p=quarantine -- Policy for failed messages: none (monitor only), quarantine (send to spam), or reject (block entirely)
rua=mailto:dmarc@yourdomain.com -- Where to send aggregate reports about authentication results

DMARC adds a critical concept called alignment: the domain in the From header must match the domain used in SPF or DKIM checks. This prevents an attacker from passing SPF with their own domain while spoofing yours in the visible From field.

Choosing a DMARC policy

Policy	Behavior	When to use
`none`	No action, just collect reports	Starting out, monitoring who sends as your domain
`quarantine`	Failed emails go to spam	You've verified all legitimate senders are authenticated
`reject`	Failed emails are blocked entirely	Full confidence in your authentication setup

Start with p=none to collect reports before moving to quarantine or reject. Jumping straight to reject can block legitimate emails if your DNS records aren't fully configured.

How Postkit handles authentication

When you add a domain to Postkit, the platform generates the DNS records you need:

DKIM key pair -- Postkit generates an RSA key pair for your domain. The private key is stored in the Postal SMTP engine. You add the public key as a DNS TXT record.
SPF record -- You add Postkit's SPF include (include:spf.postkit.eu) to your domain's existing SPF record, or create a new one.
DMARC record -- You create a DMARC record with your preferred policy. Postkit recommends starting with p=none and progressing to p=quarantine once you've confirmed your setup is working.

Once your DNS records are in place, Postkit automatically:

Signs every outbound email with your domain's DKIM private key
Sends from authorized IPs that are listed in the Postkit SPF record
Aligns the From domain so DMARC alignment checks pass

The Domain Setup guide walks through the full DNS configuration process step by step, including the exact records to add and how to verify them.

Why this matters for deliverability

Email authentication directly impacts whether your emails reach the inbox or land in spam. The major email providers enforce authentication increasingly strictly:

Gmail requires SPF or DKIM for all senders, and both SPF and DKIM for bulk senders. DMARC with at least p=none is required for bulk senders.
Microsoft Outlook uses authentication results as a primary signal for spam filtering.
Yahoo Mail requires SPF, DKIM, and DMARC for all bulk senders.

Without proper authentication:

Emails are more likely to land in spam folders
Your domain reputation suffers over time
Recipients see "via postkit.eu" warnings instead of your domain name
Phishers can more easily spoof your domain

With all three standards properly configured, receiving servers can confidently verify that your emails are legitimate, leading to better inbox placement and stronger domain reputation.

What's next?

Domain Setup guide for step-by-step DNS configuration with Postkit
Email Delivery Pipeline for the full sending flow including DKIM signing