Email Authentication: SPF, DKIM, DMARC

The main reason corporate email doesn't reach the recipient or lands in the spam folder is, in most cases, not the content but the domain's missing authentication records. SPF, DKIM and DMARC are three DNS records that answer the question "was this email really sent from this domain?". If all three aren't defined, the receiving server can't recognise the sender and treats the message with suspicion.

Why do my emails land in spam?

The main reason corporate email lands in the spam folder is not the content but the domain's missing authentication records. SPF states which servers may send on your behalf, DKIM that the message wasn't altered in transit, and DMARC what to do when verification fails. If all three aren't defined, the receiving server can't verify the sender.

Three records, three separate questions

The three complement each other. Setting up only SPF is one third of the protection.

SPF: who is authorised to send

SPF (Sender Policy Framework) is a DNS TXT record listing which servers may send email on behalf of your domain.

A simple example:

v=spf1 include:_spf.google.com include:sendgrid.net ~all

This record says: "Google Workspace and SendGrid may send on my behalf; treat messages from anyone else with suspicion."

The marker at the end matters:

• ~all (softfail): a message from a server not on the list is accepted but flagged. Used during transition.
• -all (hardfail): those not on the list are rejected. This is the target once the setup has settled.
• +all: allows everyone. Never use it; it makes SPF meaningless.

The two most common SPF mistakes

1. More than one SPF record. A domain may have only one SPF record. If there are two separate v=spf1 lines, the record is considered invalid by the standard and verification fails entirely. When adding a new service, don't open a new record; add an include: inside the existing one.

2. Exceeding the ten-lookup limit. At most 10 DNS lookups may be made when evaluating SPF. Every include: spends at least one lookup, and some providers' includes contain other includes within them. If the limit is exceeded the record returns permerror and doesn't work.

If you use five or six different services (email provider, newsletter tool, CRM, invoicing system, form service), you're likely to hit this limit. Removing services you don't use from the record is the first fix.

DKIM: was the message altered in transit

DKIM (DomainKeys Identified Mail) adds an invisible signature to every outgoing message. The receiving server verifies this signature with the public key you publish in your DNS. If the signature holds, the message wasn't altered in transit and really came from your server.

Setup depends on the provider: your email provider gives you a selector and a public key, and you add it to DNS as a TXT record:

selector1._domainkey.alanadiniz.com   TXT   "v=DKIM1; k=rsa; p=MIGfMA0GCS..."

If you send from more than one service, a separate selector is used for each; they don't clash. Unlike SPF, DKIM has no "single record" limit.

Point to watch: when you change email provider, clean up the old DKIM records. Unused keys are doors left open.

DMARC: policy and reporting

DMARC states what to do when SPF and DKIM fail. Also — the real benefit most people skip — it sends you a report of who is sending mail in your name.

_dmarc.alanadiniz.com   TXT   "v=DMARC1; p=none; rua=mailto:[email protected]; pct=100"

The policy (p=) takes three values:

• none: do nothing, just send reports. This is the starting point.
• quarantine: put failed messages in the spam folder.
• reject: reject failed messages entirely.

A gradual transition is essential

The most common mistake is starting with p=reject from day one. If a service you use but aren't aware of (invoicing system, appointment software, e-commerce notifications) isn't on your SPF list, the emails that service sends are rejected entirely and nobody notices.

The right order:

1. Start with p=none, collect the reports.
2. Add all the legitimate senders appearing in the reports to SPF and DKIM.
3. After a few weeks switch to p=quarantine; you can start with a gradual ratio like pct=25.
4. If everything is clean, move to p=reject.

This transition typically takes 4-8 weeks. The price of rushing is outgoing invoices not reaching customers.

Check your current state

To see whether your records are correct, enter your domain into our Email Health Check tool: it reads your SPF, DKIM and DMARC records and lists the gaps and errors.

If you want to see the raw DNS records, the DNS Lookup tool shows the TXT records as they are.

Checklist

• The domain has a single SPF record
• No unused services in SPF, the 10-lookup limit isn't exceeded
• SPF ends with ~all or -all (no +all)
• A DKIM selector is defined for every sending service
• Old/unused DKIM keys cleaned up
• A DMARC record exists and the rua address is monitored
• The DMARC policy is being tightened gradually
• Records reviewed when domain ownership is transferred

Frequently asked questions

How long until the records take effect? DNS propagation is usually between a few minutes and a few hours; it depends on the TTL value.

I have a domain I never send email from, is it still needed? Yes, even more so. Domains that don't send are ideal for spoofing. Give such domains v=spf1 -all and p=reject — nobody can send mail in that domain's name.

Are subdomains covered too? In DMARC the subdomain policy is set separately with the sp= parameter. If not specified, the main policy applies.

Reading the reports

When you write a rua= address in the DMARC record, receiving servers start sending you daily XML reports. Their raw form is hard to read, but the information inside is valuable:

• Which IP addresses are sending mail in your domain's name
• How many of these sends pass SPF and DKIM verification
• Which service the failures come from

If you see an unexpected sender in the reports there are two possibilities: either a legitimate service you forgot (an old form tool, accounting software) or someone imitating your domain. Both are things you need to know.

We recommend directing the report address to a separate mailbox rather than your corporate email; the daily volume can be high.

SPF records for common providers

If you don't know the include: value of the service you use, it's found under the "SPF record" heading in the provider's documentation. Commonly used ones:

You combine these in a single record:

v=spf1 include:_spf.google.com include:sendgrid.net ~all

If mail also goes out from your hosting provider's server (like contact form notifications), you also need to add its IP address, in the form ip4:203.0.113.10.

BIMI: your logo in the inbox

If you've brought DMARC to the quarantine or reject level, you can take one more step. BIMI (Brand Indicators for Message Identification) lets your brand's logo appear in the recipient's inbox.

Its requirements:

• DMARC policy at least quarantine
• The logo published in SVG Tiny PS format
• For some providers, a Verified Mark Certificate (VMC)

Not mandatory, but it makes a noticeable contribution to corporate visibility. Worth considering if you've completed your authentication chain.

Domain transfer and migration

The most common problem when changing email provider is records being left half-done during the transition. Proceed in order:

1. Add the new provider to the SPF record (don't remove the old one yet).
2. Publish the new DKIM selector.
3. Move sending to the new provider.
4. Watch the reports for a few days.
5. Remove the old provider from SPF and the old DKIM record from DNS.

If you need to move your existing mailboxes to the new server, the IMAP Migration tool transfers while preserving the folder structure.

Automate the check

Once set up, the records are forgotten; but DNS changes, provider updates or a new record added by a plugin can silently break the structure. Make checking every three months a habit.

For a quick check it's enough to enter your domain into the Email Health Check tool; you see the SPF, DKIM and DMARC state on a single screen.

Setting up these three records is a one-off, but when done wrong it does silent damage: you usually find out your emails aren't arriving when a customer says "I wrote to you".

You can audit your domain's current state with the Email Health Check.