Cyber Security
SPF, DKIM and DMARC explained: protecting your email domain
Without SPF, DKIM and DMARC, almost anyone can send email in your domain's name. Here is how the three records work and how to introduce them without losing legitimate mail.
Q-entra editorial teamPublished on 6 min read
Contents
- What SPF, DKIM and DMARC do: the short answer
- SPF: who may send email for your domain?
- DKIM: a digital signature for every message
- DMARC: policy and reporting for your domain
- Rolling out step by step without blocking legitimate email
- What large mailbox providers now require
- Protecting inbound email as well
- Conclusion: record, monitor, then enforce
Key takeaways
- SPF defines which servers may send email for your domain, DKIM signs every message, and DMARC decides what happens to emails that fail these checks.
- DMARC checks whether SPF or DKIM matches the visible sender address and reports who sends email in your name.
- Roll out DMARC gradually: record every sender first, monitor with p=none, then move via quarantine to reject.
- Gmail, Yahoo and Outlook.com require SPF, DKIM and DMARC from bulk senders.
- Your own inbox also needs a filter that recognises lookalike domains and dangerous links.
What SPF, DKIM and DMARC do: the short answer
SPF, DKIM and DMARC are three DNS records for your domain that together show whether an email really comes from you. SPF defines which servers may send email for your domain. DKIM adds a digital signature to every message. DMARC links both to the visible sender address, specifies what should happen to forged emails and sends you reports.
Without these entries, almost anyone can send emails that appear to come from your domain, such as fake invoices to your customers. At the same time, large mailbox providers increasingly expect proper authentication before they deliver email. The good news is that an orderly rollout solves both without losing legitimate mail.
SPF: who may send email for your domain?
With SPF (Sender Policy Framework), you publish a list in DNS of the servers and services that are allowed to send email for your domain. The receiving server checks whether the IP address delivering the message is on that list. Note that SPF checks the technical sender address (envelope sender or Return-Path), not the address the recipient sees in their email program.
Each domain may have only one SPF record. Services are usually added with an include, for Microsoft 365 for example include:spf.protection.outlook.com. There is a limit of ten DNS lookups: if you include many services, you can exceed it quickly, and the SPF check then ends in an error that DMARC treats as a failure. SPF also often breaks when messages are forwarded, because a different server then delivers the email.
DKIM: a digital signature for every message
With DKIM (DomainKeys Identified Mail), the sending server signs every message with a private key. You publish the matching public key in DNS under a so-called selector. The recipient uses it to check whether the email really comes from an authorised system and was not altered on the way.
Unlike SPF, DKIM usually survives simple forwarding, as long as nobody changes the content or the signed headers. Make sure every service signs with your own domain and not only with the provider's domain. A key length of 2048 bits is common today.
DMARC: policy and reporting for your domain
DMARC (Domain-based Message Authentication, Reporting and Conformance) connects both with the sender address the recipient actually sees. An email passes DMARC if SPF or DKIM succeeds and the checked domain matches the visible From address, which is called alignment. In the DMARC record you also specify what should happen to emails that fail:
- p=none: monitor only. Emails are delivered as usual, but you receive reports.
- p=quarantine: receivers should treat failing emails as suspicious, which usually means the spam folder.
- p=reject: emails that fail the check are refused. This is the goal.
Through the rua tag, receiving providers send you aggregate reports in XML format, usually daily: which servers sent email in your name, how many messages there were and whether SPF and DKIM passed. These reports do not contain the content of the emails. Because the raw data is hard to read, an analysis service or a suitable tool is worthwhile.
| Method | What it checks | DNS entry | Limitation |
|---|---|---|---|
| SPF | Whether the sending server is authorised | TXT record on the domain | Breaks on forwarding, ignores the visible address |
| DKIM | Whether the email is signed and unchanged | Public key under a selector | Signing domain need not match the visible address |
| DMARC | Whether SPF or DKIM matches the visible sender domain | TXT record under _dmarc | Needs correct SPF or DKIM, does not catch lookalike domains |
Rolling out step by step without blocking legitimate email
A typical mistake is to set DMARC to reject straight away. Invoices from the accounting software or the newsletter then suddenly end up in spam or are not delivered at all. This sequence is safer:
- Record every sender: mail server or Microsoft 365, newsletter tool, CRM, invoicing and accounting software, web shop, ticket system, website contact form, multifunction printers and external agencies.
- Clean up SPF: create a single record containing all authorised services, check the ten-lookup limit and start with ~all.
- Enable DKIM for each service: with your own domain, not the provider's. In Microsoft 365, for example, DKIM has to be switched on explicitly for your own domains.
- Start DMARC in monitoring mode: for example with v=DMARC1; p=none; rua=mailto:dmarc@example.com, and analyse the reports for a few weeks.
- Close the gaps: authenticate unknown but legitimate senders properly, or move them to a subdomain such as news.example.com with its own SPF and DKIM.
- Tighten gradually: switch to p=quarantine, keep watching the reports and then move to p=reject.
- Maintain permanently: every new tool that sends email is added to SPF and DKIM before it goes live.
What large mailbox providers now require
Since 2024, Google has required senders who send around 5,000 or more messages a day to personal Gmail addresses to use SPF, DKIM and a DMARC record with at least p=none, and the visible sender domain must align with SPF or DKIM. Marketing emails also need one-click unsubscribe. Yahoo introduced comparable rules at the same time, and since 2025 Microsoft has applied similar requirements at Outlook.com to senders of around 5,000 or more messages a day. Google expects at least SPF or DKIM from all other senders.
BIMI: your logo in the inbox
BIMI (Brand Indicators for Message Identification) displays your company logo next to authenticated messages in supporting email programs. It requires a DMARC policy in enforcement mode, meaning quarantine or reject, and a logo in a special SVG format. Some providers, such as Gmail, also require a paid certificate for the logo. BIMI is a visible bonus, not a security feature in itself.
Protecting inbound email as well
SPF, DKIM and DMARC on your own domain mainly protect others from forgeries in your name. Your own inbox also needs a filter that checks incoming emails and detects attacks from external, similar-looking domains, because DMARC only protects domains you own, not lookalike variants with typos. Look out for the following:
- Incoming emails are checked for SPF, DKIM and DMARC, and the senders' DMARC policies are respected.
- Protection against lookalike domains and against emails impersonating management or well-known partners.
- Checking of links and attachments, ideally also at the moment of clicking.
- A visible notice for external senders and a simple report button for suspicious messages.
Even the best filter occasionally lets something through. Our article on the warning signs of phishing explains how your team can recognise dangerous messages. For Microsoft 365 environments, our article on securing Microsoft 365 covers the relevant settings.
Conclusion: record, monitor, then enforce
SPF, DKIM and DMARC are not a one-off project, but they are not a major effort either if you proceed in a structured way: record every sender first, then monitor, then enforce step by step. In the end, forging email with your domain becomes much harder, and your legitimate emails arrive more reliably. If you would like support with the setup or with analysing the reports, Q-entra can help as part of cyber security.
