Email authentication is the set of standards that let a receiving mail server check whether a message was sent with the authorization of the domain it claims to be from. It confirms that the sending system was authorized by the domain owner, or that the message was signed with the domain’s key, and that this lines up with the visible From address; it does not prove who the human sender is or that the message is trustworthy. The three core standards are Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM) and DMARC, each published as records in your domain’s DNS. Used together, they make it much harder for attackers to send email that impersonates your domain and help your legitimate mail reach inboxes.
At a glance
- SPF lists which servers may send mail for your domain; DKIM adds a cryptographic signature; DMARC ties both to the visible From address and sets a policy.
- All three are published in the Domain Name System (DNS) and checked by the receiving mail server.
- DMARC reports show who is sending mail as your domain, including services you forgot and attackers spoofing you.
- Several large mailbox providers expect SPF, DKIM and DMARC from bulk senders, and mail that fails may be filtered or rejected.
- Authentication checks domain authorization, not the sender’s identity or intent: it does not stop look-alike domains or mail sent from compromised real accounts.
What problem it solves
The original email system has no built-in way to check whether a sender is authorized to use a domain. The basic protocol lets a sender put almost any address in the From line, which is why spoofed invoices, fake executive requests and phishing messages that appear to come from your own domain are so common. Spoofing is a frequent starting point for business email compromise (BEC).
Without authentication, receiving servers also have little to go on when deciding whether your real mail is trustworthy, so legitimate invoices, password resets and marketing messages can end up in spam. Email authentication addresses both sides: it lets receivers reject mail that falsely claims your domain, and it lets your real mail show that your domain authorized it.
How it works
SPF. You publish a DNS record listing the mail servers and services allowed to send mail for your domain. The receiving server checks whether the connecting server is authorized for the envelope sender’s domain. SPF checks the hidden envelope sender, not the From address users see, and it can break when mail is forwarded.
DKIM. Your mail system or sending service signs each outgoing message with a private key. You publish the matching public key in DNS. The receiver uses it to confirm the message was signed by a holder of your domain’s key and that the signed parts were not altered in transit. DKIM signatures often survive forwarding.
DMARC. You publish a DMARC policy that tells receivers to check whether SPF or DKIM passes and lines up (“aligns”) with the domain in the visible From address. The policy says what to do on failure: monitor only, quarantine (usually send to spam), or reject. Receivers send aggregate reports back to an address you choose, showing which sources send mail as your domain and whether they pass.
Rollout. Most organizations start DMARC at a monitoring policy, use the reports to find every legitimate sender, such as their email platform, CRM, marketing, billing and help desk tools, configure SPF and DKIM for each, then move step by step to quarantine and reject.
When it matters for buyers
- When your domain is being spoofed. Customers or staff receiving fake mail “from” you is the clearest trigger.
- When deliverability drops. Mail landing in spam or being rejected by large providers often traces back to missing or misaligned records.
- When adding a new sending service. Each new CRM, marketing or ticketing platform needs SPF and DKIM set up before it sends as your domain.
- When choosing email security. A secure email gateway (SEG) or email security service checks inbound authentication; some providers also offer DMARC reporting and management.
- When insurers or customers ask about email security. Questionnaires increasingly ask whether DMARC is enforced.
Questions to ask vendors
- For email security providers: do you check SPF, DKIM and DMARC on inbound mail, and how do you treat failures?
- Do you offer DMARC report analysis or managed rollout to an enforcing policy?
- For sending platforms: do you support DKIM signing with our own domain, and custom return-path domains for SPF alignment?
- How many DNS lookups will your SPF include add? SPF has a lookup limit that large include chains can exceed.
- Who will monitor DMARC reports after rollout, and how will new senders be added?
How it differs from email encryption
Email authentication checks that a message was authorized by the domain it claims and, with DKIM, that the signed content was not altered; it does not hide the message’s content. Email encryption protects the content from being read in transit or at rest, using transport encryption between servers or end-to-end message encryption. Organizations usually need both, and they are configured separately. For filtering and protecting inbound mail, see our secure email gateway overview.