Sending an email in someone else's name is, technically, one of the simplest attacks that exists. The SMTP protocol that moves all the world's email was designed in 1982, at a time when the Internet was a network of trust between universities and research centres. Authenticating who sent a message simply was not a concern, and that original sin is still with us today: by default, anyone can write whatever sender they want in the From header of an email.
That forging of the sender, known as spoofing, is the basis of most phishing campaigns and of BEC (Business Email Compromise) fraud, in which an attacker impersonates an executive or a supplier to authorise a transfer or steal credentials. BEC losses run into billions of euros a year, and it all starts with a simple email that appears to come from a legitimate domain.
The industry's answer to this problem is three authentication mechanisms that work in layers: SPF, DKIM and DMARC. Configuring them correctly not only protects your brand from impersonation: it is also what makes your legitimate emails reach the inbox instead of ending up in the spam folder. In this article we explain what each one does, how they complement each other and the recommended path to deploy them without breaking anything.
Why Email Needs Authentication
When a mail server receives a message, it has to answer a seemingly simple question: does this email really come from who it says it does? Without any authentication mechanism, the only possible answer is an act of faith. The From field the user sees is free text that the sender fully controls, just like the return address handwritten on the envelope of a postal letter: nobody checks that it matches who actually sent it.
This lack of verification has two direct consequences. The first is about security: an attacker can send emails that appear to come from your domain in order to deceive your customers, employees or suppliers. The second is about deliverability: because mail providers cannot tell your legitimate domain from an impostor, they apply aggressive reputation filters and, when in doubt, send your messages to spam. Authentication solves both problems at once, and it is as important to security as SSL/TLS certificates are to web traffic.
The three pillars of email authentication all rely on the domain's DNS, where the records that receiving servers query to validate each message are published. If you want to properly understand the infrastructure everything sits on, we have a dedicated guide on how DNS works and why it matters so much. Let's now look at each of the three mechanisms.
SPF: Who Can Send on Your Behalf
SPF (Sender Policy Framework) is the oldest and simplest of the three. It consists of a DNS TXT record published on your domain that lists which servers are authorised to send email on its behalf. When a receiving server gets a message, it checks the IP address of the sending server against that list: if the IP is authorised, the mail passes SPF; if not, it fails.
A typical SPF record looks like this: v=spf1 include:_spf.google.com include:sendgrid.net ~all. The include mechanisms delegate authorisation to the third-party servers that send for you (your mail provider, your email marketing platform, your CRM), and the end of the record defines the policy. This is where a key distinction appears: ~all (softfail) says that mail from unlisted servers is suspicious but should still be accepted, whereas -all (hardfail) says it should be rejected outright. During the testing phase you use ~all; in production, with a well-tuned SPF, the correct choice is -all.
SPF has a very important technical limitation you must respect: the 10 DNS lookups limit. Every include, a, mx or redirect in the record triggers an additional resolution, and if expanding all the nested include entries exceeds ten lookups, the record is marked as permerror and validation fails even when the mail is legitimate. This limit is the number one cause of SPF breaking down once a company accumulates too many third-party services. On top of that, SPF has a structural weakness: it does not survive forwarding, because forwarding a message changes the sending server and the original IP disappears.
DKIM: The Cryptographic Signature of the Message
DKIM (DomainKeys Identified Mail) addresses SPF's shortcomings with a cryptographic approach. Instead of verifying the sending server's IP, DKIM adds a digital signature to the header of every outgoing email. The sending server signs selected parts of the message (headers and body) with a private key that only it knows, and publishes the corresponding public key in a DNS TXT record. The receiver retrieves that public key, verifies the signature and confirms two things: that the message really comes from the domain and that it has not been altered in transit.
DKIM's big advantage over SPF is that the signature travels inside the email itself, so it survives forwarding: as long as the signed content is not modified, validation stays valid even if the message passes through several intermediate servers. This makes it far more robust for real-world mail distribution scenarios.
DKIM uses the concept of a selector, an identifier that lets you have several keys published at once under the same domain (for example selector1._domainkey.yourdomain.com). Selectors make key rotation possible: publish a new key, start signing with it and retire the old one without interrupting service, a security best practice worth carrying out periodically to limit the impact of a compromised key. Each third-party sending service usually has its own selector and its own key, which avoids the lookup problem SPF suffers from.
DMARC: The Policy and the Visibility
DMARC (Domain-based Message Authentication, Reporting and Conformance) is the piece that ties SPF and DKIM together and gives them meaning. On their own, SPF and DKIM validate the mail, but they do not tell the receiver what to do when validation fails, nor do they inform the domain owner of what is going on. DMARC is a DNS TXT record published at _dmarc.yourdomain.com that solves exactly that. You can dig deeper into the specification and official tooling at dmarc.org.
DMARC contributes three things. The first is the policy, defined by the p parameter, which tells the receiver what to do with mail that does not pass authentication: p=none (do nothing, just observe), p=quarantine (send to spam) or p=reject (reject the message). The second is alignment: DMARC requires that the domain validated by SPF or DKIM matches the domain visible in the From header, closing the gap through which an attacker could pass SPF with their own domain while forging the sender the user sees.
The third contribution, and probably the most valuable at first, is the aggregate reports. Through the rua parameter you define an email address to which receiving providers send daily XML reports with statistics on all the mail that claims to come from your domain: which IPs send, how much passes SPF and DKIM, and how much fails. These reports give you full visibility of who sends in your name — including impostors and legitimate services you had forgotten — and they are the foundation on which a safe DMARC deployment is built.
How the Three Work Together
The clearest way to understand how the three relate is to think of complementary layers. SPF validates the sending server, DKIM validates the message through cryptography, and DMARC validates that both are aligned with the visible domain and decides what to do if they are not. An email passes DMARC if SPF or DKIM validate correctly and are aligned with the From; it is enough for one of the two to work, which provides redundancy. The following table summarises what each mechanism validates, where it is published and what it protects:
| Mechanism | What it validates | DNS record | What it protects |
|---|---|---|---|
| SPF | That the sending server's IP is authorised | TXT on the root domain | Sends from unauthorised servers |
| DKIM | The cryptographic signature of the message | TXT on selector._domainkey |
Integrity and origin of the content |
| DMARC | Alignment with the From domain and the policy | TXT on _dmarc |
Spoofing of the visible sender |
Alignment is the key:
An email can pass SPF and DKIM and still fail DMARC if the authenticated domain does not match the one the user sees in the From. That alignment check is what makes DMARC the real defence against spoofing, not the mere sum of the other two.
The Step-by-Step Implementation Path
Deploying DMARC is not about publishing a record and forgetting it: it is a gradual process designed not to bounce legitimate mail along the way. The recommended order is always the same:
- check_circle Publish SPF and DKIM first: make sure your mail provider and all your sending services have their SPF records and DKIM selectors correctly configured before touching DMARC.
-
check_circle
Start with
p=none: publish DMARC in monitoring mode with aruaaddress to receive reports. In this phase nothing is blocked; you just observe who sends in your name for several weeks. - check_circle Fix your legitimate sources: analyse the reports, identify all the real services that send for you (marketing, billing, CRM, ticketing) and align them until 100% of your legitimate mail passes authentication.
-
check_circle
Tighten to
p=quarantineand thenp=reject: once you are sure that only your legitimate sources pass validation, raise the policy progressively up to the full rejection of spoofed mail.
Once you reach p=reject, there is an optional extra step: BIMI (Brand Indicators for Message Identification). BIMI lets you display your brand's verified logo next to your emails in the inbox of compatible providers, which boosts recognition and trust. It requires DMARC on a strict policy as a prerequisite, so it is the natural reward for a well-executed authentication rollout.
This process is no longer optional. Since 2024, Google, Yahoo and Microsoft require email authentication — SPF, DKIM and a DMARC policy of at least p=none — from senders that send large volumes of messages, and they reject or mark as spam any mail that does not comply. What used to be a recommended best practice is now an entry requirement for your campaigns and notifications to reach the inbox.
Common Mistakes to Avoid
Most authentication problems do not come from the theory, but from specific configuration oversights. These are the most frequent ones:
-
arrow_right
SPF with too many
includeentries: exceeding the 10 DNS lookups limit invalidates the whole record with apermerror. It is worth consolidating services and, if necessary, using record flattening techniques. - arrow_right Forgetting third-party services: platforms like Mailchimp, your CRM, the billing tool or the ticketing system send mail in your name. If you do not include them in SPF and DKIM, their legitimate mail will fail authentication.
-
arrow_right
Setting DMARC to
rejectwithout monitoring: jumping straight to the rejection policy without having analysed the reports bounces legitimate mail and can leave your company unable to send invoices or critical notifications. -
arrow_right
Ignoring the
ruareports: publishing DMARC and never reading the reports wastes its biggest advantage. They are the only way to detect spoofing and misconfigured legitimate sources.
These failures are not only technical: a domain without authentication is an open vector for the phishing and social engineering campaigns that impersonate your brand to deceive third parties. The impact of doing it right is twofold: it improves deliverability (your emails don't land in spam) and provides brand protection (nobody can send fraudulent mail that appears to come from your domain).
How EasyDataHost Helps You
Configuring SPF, DKIM and DMARC correctly requires knowing the domain's DNS infrastructure, identifying every sending source and tuning the records without disrupting production mail. At EasyDataHost we help our customers configure the DNS authentication records for their corporate email as part of our security and infrastructure services:
- arrow_right Design and publication of optimised SPF records that respect the 10 lookups limit even with multiple third-party services.
- arrow_right Configuration of DKIM keys and selectors with periodic rotation for each sending platform.
-
arrow_right
Gradual rollout of DMARC from
p=nonetop=reject, with analysis of the aggregate reports at every phase. - arrow_right Integration of email authentication into an overall managed security strategy, in our own datacenter in Spain.
All of it backed by our ISO 27001 certified, ENS-compliant infrastructure. If your corporate email does not yet have the three pillars in place, it is one of the highest-return security improvements you can implement.
Frequently Asked Questions
Which is more important: SPF, DKIM or DMARC?
The three complement each other and are not alternatives. SPF and DKIM are the mechanisms that authenticate the send; DMARC is the policy that tells the receiver what to do when they fail and, above all, provides visibility through aggregate reports. Without correctly aligned SPF or DKIM, DMARC cannot validate anything, so you need all three working together.
Can I set DMARC to p=reject straight away?
It is not advisable. Always start with p=none to monitor the aggregate reports for several weeks, identify all your legitimate email sources (CRM, billing, marketing) and fix their alignment. Only when 100% of your legitimate email passes authentication should you tighten to quarantine and then reject. Jumping straight to reject without monitoring bounces legitimate mail.
Does authentication guarantee my email won't land in spam?
It helps decisively, but it is not the only factor. SPF, DKIM and DMARC are an entry requirement for large providers such as Google, Yahoo and Microsoft, and without them much of your mail ends up in spam or gets rejected. Even so, deliverability also depends on IP reputation, content quality, complaint rate and blocklists. Authentication is the essential foundation on which everything else is built.
Conclusion
Email will keep running on a protocol that was born without security, but that does not mean you have to accept its risks. SPF, DKIM and DMARC turn a system open to impersonation into an authenticated, trusted channel:
-
arrow_right
SPF lists which servers can send on behalf of your domain, respecting the 10 lookups limit and using
-allin production. - arrow_right DKIM cryptographically signs every message, guaranteeing its integrity and origin, and survives forwarding thanks to rotatable selectors.
- arrow_right DMARC aligns authentication with the visible sender, defines the policy (none, quarantine, reject) and provides the visibility of the aggregate reports.
-
arrow_right
The gradual rollout — from
p=nonetoreject, with BIMI as a reward — improves deliverability and protects your brand, and is now a requirement from Google, Yahoo and Microsoft.