SPF, DKIM and DMARC help receiving systems spot forged emails sent using your domain. Learn what each one does and how to move DMARC in stages from p=none to reject.
If an email saying "our bank account has changed" reached your customer from your domain, could they tell it didn't come from you? Email's basic design does not check on its own that the sender address is genuine; someone with bad intentions can put your address in the "From" field and send a message. SPF, DKIM and DMARC are three complementary mechanisms, defined in your domain's DNS records, that help receiving systems tell such forged messages apart.
Why are they needed?
These records address two separate problems. The first is spoofing: fraudsters using your domain to send payment requests or links to fake password pages to your customers, suppliers or staff. The second is deliverability: your own invoices, quotes and notifications landing in the recipient's junk folder. Large email providers increasingly expect sending domains to authenticate themselves; for high-volume senders in particular, these records have become a basic requirement.
SPF: who can send on your behalf?
SPF (Sender Policy Framework) is the list of servers and services authorised to send email on behalf of your domain. It is added to your domain's DNS as a text (TXT) record beginning with "v=spf1". The receiving server checks whether the server that sent the incoming message is on this list.
Common SPF mistakes include:
- Forgotten sending sources: Adding only your main email service is not enough. Your invoicing software, bulk email tool, customer management application, the contact form on your website and printers that scan to email may all be sending on your behalf.
- More than one SPF record: A domain should have only one SPF record. Creating a second record when adding a new service causes SPF checks to fail; the new source should be added to the existing record.
- DNS lookup limit: An SPF check may perform no more than 10 DNS lookups. When many services are added with "include", this limit can be exceeded and the record treated as invalid.
The term at the end of the record says what to do with sources not on the list: "~all" suggests marking them as suspicious, "-all" suggests rejecting them. SPF also has a limitation: it checks the message's behind-the-scenes return address, not the "From" address the recipient sees on screen. And when a message is automatically forwarded to another address, the SPF check often fails. DKIM and DMARC close these gaps.
DKIM: did the message really come from you, unchanged?
DKIM (DomainKeys Identified Mail) means the sending server adds a digital signature to each message. The signature is created with a private key; the matching public key is published in your domain's DNS. The receiving server verifies the signature with that public key and confirms that the message really was sent on behalf of your domain and was not altered on the way.
DKIM's advantage is that the signature travels with the message, so it often stays valid even when a message is forwarded. DKIM must be enabled separately for each sending service: having DKIM on in your main email service does not sign the messages your invoicing software sends. The common recommendation for key length is 2048 bits, and renewing keys at intervals is good practice.
DMARC: what happens if authentication fails?
DMARC (Domain-based Message Authentication, Reporting and Conformance) brings SPF and DKIM together and tells the recipient a policy. It is a TXT record added under the "_dmarc" name in DNS. The key DMARC concept is "alignment": for a message to pass, at least one of SPF or DKIM must succeed, and the authenticated domain must match the domain in the "From" address the recipient sees. This fixes SPF's problem of not checking the visible address.
DMARC's second important contribution is reporting. Receiving systems send aggregate reports about messages sent with your domain to the address you specify in the record. These reports are in a technical format and are usually reviewed with a report-reading tool, but they are the most practical way to see which sources are sending on your behalf and which are failing authentication.
| What it does | Common mistake | |
|---|---|---|
| SPF | Lists the servers allowed to send on your behalf | Forgetting a sending service, having more than one record |
| DKIM | Signs the message, verifying its source and integrity | Enabling it only on the main email service |
| DMARC | Says what to do with failing messages, collects reports | Leaving it in monitoring mode for years |
How to see where you stand
You don't need a technical project to get started. Send a message from your own address to an external email account, and on the receiving side open the message's "original" or "headers" view. In the "Authentication-Results" line you will see "pass" or "fail" for spf, dkim and dmarc. Repeat this test for your other sending sources, such as the invoicing software and the contact form. You can also view your domain's DNS records with free online DNS lookup tools.
Moving to DMARC in stages
Setting the DMARC policy to its strictest level on day one can cause messages from a forgotten sending source to be rejected. The safe route is to proceed in stages:
- Inventory: List every service that sends email using your domain; ask the accounting, sales and marketing teams too.
- SPF and DKIM: Add each source to the SPF record and enable DKIM in each service.
- p=none: Publish the DMARC record in monitoring-only mode. At this stage message delivery is not affected; reports are simply collected. Watch the reports for a few weeks and fix legitimate sources that fail authentication.
- p=quarantine: Ask for messages that fail authentication to be placed in the junk folder. If you wish, you can use the "pct" setting to apply this policy to a portion of messages first.
- p=reject: Once the reports look clean, ask for messages that fail authentication to be rejected. This stage gives the strongest protection against spoofing.
The most common problem is DMARC being left at p=none and forgotten. Monitoring mode gathers information but does not stop forged messages, so set a timeline for the transition from the start.
Domains you don't send email from need protecting too. Publishing an SPF record containing "v=spf1 -all" and a DMARC record with a p=reject policy on unused domains, or ones bought only for a website, makes it harder for them to be used in forged emails.
What these records can't do
SPF, DKIM and DMARC make exact impersonation of your domain harder, but they don't solve everything. Fraudsters can register a different domain that looks very like yours, for example by changing a single letter, and set up complete records for that domain. A message sent from a genuine but compromised employee account will also pass every check. That is why multi-factor authentication on accounts, staff awareness and confirming requests such as a change of bank account through a separate, previously known channel complement these records.
Checklist
- Have all services that send email using your domain been listed?
- Does your domain have a single, up-to-date SPF record that stays within the DNS lookup limit?
- Is DKIM signing enabled for every sending service?
- Has a DMARC record been published, and are its reports reviewed regularly?
- Is there a timeline for moving from p=none to the quarantine and reject stages?
- Have SPF and DMARC records been set up for your domains that don't send email?
- Are requests to change payment or account details confirmed through a second channel?