SPF, DKIM and DMARC explained in plain English

What are SPF, DKIM and DMARC?#

Three text records your domain publishes about itself. SPF lists the mail servers allowed to send as you. DKIM puts a signature on each message. DMARC tells a receiver what to do when either check fails, and asks to be told about it.

They are not three versions of one thing, and that is why having two of them is a normal way to still fail.

What does an SPF record say?#

It is a text record on your domain that begins with v=spf1 and then lists who is permitted to send for you. The receiver checks it against the machine that handed the message over, so it answers one narrow question about the sending server, not about the message or the person reading it.

The last term is the instruction for anything not on the list. RFC 7208, the SPF standard, is careful about the two endings people mix up: a fail result is an explicit statement that the client is not authorised to use that domain, while a softfail result is only a weak statement that the host probably is not.

How many SPF records may a domain have?#

The merge is one line. Take the include address your new sending service publishes and add it to the record you already have, keeping whatever the old record already permitted. Two services, one record.

What does a DKIM record say?#

DKIM answers a different question: did this message come from the domain in the From line, and did anybody change it in transit? The sending server signs the message with a private key it holds, and the public half of that pair sits in your DNS for receivers to fetch.

RFC 6376, the DKIM standard, says the DKIM-Signature header field contains all of the signature and key fetching data. Two tags inside it are worth knowing by name, because they are what you read when something is broken. The d= tag is the domain claiming responsibility for the message, and the s= tag is the selector, which subdivides the namespace so one domain can publish several keys.

Those two values build the DNS name a receiver asks for, and the standard gives the shape directly: for a selector of foo.bar under example.com, the query is for foo.bar._domainkey.example.com.

What does a DMARC record say?#

DMARC is your instruction to the receiver, published at _dmarc under your domain. It names an address that should be sent the reports, and its p= tag says what to do with mail that fails: none, quarantine or reject.

The part people miss is alignment. DMARC passes only when the domain in the From line matches the domain that passed SPF or the domain that signed the message. The record controls how exact that match must be, and the tag for it is short: adkim=s means strict DKIM alignment, and leaving it out allows a relaxed match.

So a domain can have a perfect SPF record and a perfect DKIM record and still fail DMARC, because neither one is the address your reader sees. That mismatch, not a missing record, is what most setup pages leave out.

Do I need all three?#

The big mailbox providers publish bulk sender guidance. Gmail and Yahoo state theirs as requirements for high volume senders: authenticated sending, a one click way to leave the list, and complaint rates kept low. Microsoft publishes sender guidelines for Outlook and Hotmail on the same ground.

None of them publishes the exact number at which a domain starts getting blocked, and the rules change without notice. So treat the three records as the part you control, and be suspicious of any article that quotes you a precise percentage as though the mailbox told them.

What does Outlook require from a domain that sends a lot?#

Microsoft published its own version in April 2025, aimed at Outlook.com, the consumer service that also answers for hotmail.com and live.com addresses. Its wording for a domain sending more than 5,000 emails a day is short: SPF must pass for the sending domain, DKIM must pass, and DMARC must be at least p=none and aligned with either SPF or DKIM, with both preferred.

Microsoft states the order of consequences too. Non-compliant mail is routed to the junk folder first and only becomes a rejection if nothing changes. The rejection carries a code of its own: from May 5, 2025, a domain that does not meet the required authentication level gets a 550 5.7.515 access denied reply that names the sending domain. Seeing that line in a bounce is not a verdict on your writing and not a problem with your list. It says one of the three records above is not passing.

Above the records, Microsoft lists hygiene in its own words: a From or Reply-To address that is valid, reflects the true sending domain and can receive replies; a visible way to leave marketing mail; removing addresses that fail; and subject lines that do not mislead. It reserves the right to filter or block a sender that ignores them.

Why can't I do this with a Gmail or Outlook address?#

All three records live in the DNS of the domain in your From line, and only the owner of that domain can add them. A Gmail, Outlook or Yahoo address is somebody else's domain: their records already exist, and none of them permit your sending tool. That is why mailing a list from a personal address has placement problems that no rewrite of the email will touch.

What do the authentication error codes mean?#

Each of those is a different fault with a different repair, which is why a search for the word in one of them beats asking for a general fix. Read the line the receiving server wrote rather than the summary a dashboard gives you.

How do I set them up without reading DNS docs?#

1. Pick the domain that will appear in the From line. It has to be one you can add records to.
2. Ask your sending service for its DKIM records and the include address for SPF.
3. Add the DKIM records exactly as given. Some services publish more than one selector.
4. Edit your one SPF record to include the new service, rather than adding a second SPF record.
5. Publish DMARC at _dmarc with an address you will read and a policy of none to start.
6. Send a real message, view its source, and confirm the d= value is the domain your reader sees.
7. Read the reports for a few weeks. Only move from none to quarantine when your own mail is shown passing.

Step three is the one a tool can do alongside you. Campaign Kicker hands you the signature records for your domain as rows to paste and then checks them, so you know whether they are visible yet instead of guessing. SPF and DMARC stay your calls, because both depend on every other service that sends mail for your domain, and a tool that edits them without asking can take your invoices or your website forms down with it.

Why is my SPF record not working?#

Five causes cover most of what people report, and the first two are the ones a checker warns about and people skip.

1. Two records on one domain, which the standard forbids, added because a second service told you to publish an SPF record and nobody told you to merge it into the one you had.
2. Too many lookups. The same standard limits the terms that cause a DNS query (include, a, mx, ptr, exists and the redirect modifier) to ten during one evaluation, and says an implementation must return permerror above that. Four services, each with its own include chain, gets near the limit faster than it sounds. The terms that do not count are all, ip4, ip6 and exp.
3. A sending service that is not in the record, so the check runs honestly and the answer is no.
4. A relay in the middle, since a forwarder or a mailing list hands your message over from its own server rather than from yours.
5. A record published on the wrong name, most often a subdomain that sends while the From line carries the parent domain.

Settle which one it is from a header rather than from a checker. The receiving server writes the host it tested into the Authentication-Results line, and comparing that host with the servers your record lists answers the question in one read.

Why does DKIM verification fail?#

• The selector was never published, so the receiver asks DNS for a key that does not exist.
• The key is shorter than the mailbox accepts. Google requires 1024 bits or longer for personal Gmail accounts and recommends 2048 where the provider supports it.
• Somebody changed the message after signing: a footer added by a company filter, an anti-virus proxy, or a tool that appends its own unsubscribe line.
• A signed header was rewritten afterwards, which is common with Subject and From when mail passes through a forwarding rule.
• The key was rotated and the older record is still published, so the signature names a selector holding a different value.
• The d= value is not your domain at all, which is what a shared sending address looks like from the receiver's side.

The middle three are damage done in transit rather than damage done at setup, which is why a first send looks perfect while a forwarded copy of the same message fails. Compare what you sent with what a reader received before you change a record.

What breaks most often?#

• Two SPF records, added instead of merged.
• A selector that arrived with a new sending service and was never published.
• A DMARC policy of reject on day one, before any report proves the legitimate mail passes.
• A From address on a domain you do not own, where none of the three are even possible.
• Records that were correct and were never rechecked after a hosting move.

Common questions