What is Email Spoofing?
Email was designed in the 1970s when security was an afterthought. By default, any mail server can claim to send email from any address — including ceo@yourcompany.com. This is called email spoofing.
Attackers exploit spoofing to impersonate trusted brands in phishing campaigns. When a spoofed email appears to come from your domain, the reputational damage is yours to absorb.
Three complementary standards were created to solve this problem: SPF, DKIM, and DMARC. Each plays a distinct role, and all three work together to verify that incoming email genuinely came from an authorised source.
SPF – Sender Policy Framework
SPF lets you publish a list of mail servers authorised to send email for your domain. You add a TXT record to your DNS:
v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.5 ~all
When a receiving mail server gets a message claiming to be from your domain, it checks whether the sending IP is in your SPF record.
How SPF Works
- Your mail server sends a message from
user@example.com. - The receiving server extracts the domain from the envelope sender address.
- It queries DNS for the SPF TXT record of that domain.
- It checks whether the sending IP is listed.
- If the IP matches, SPF passes. If not, SPF fails.
SPF Limitations
SPF only checks the envelope sender, not the From: header users actually see. Attackers can pass SPF while still spoofing the visible From address. SPF also breaks when email is forwarded. This is why SPF alone is not sufficient — DKIM and DMARC are also needed.
DKIM – DomainKeys Identified Mail
DKIM adds a cryptographic digital signature to outgoing email. Your mail server signs each message with a private key; the matching public key lives in DNS. Receiving servers verify the signature and confirm the message is authentic and unmodified.
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1;
h=from:to:subject:date;
bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
b=AuUoFEfDxTDkHlLXSZEpZj79LBjnwhB7...
How DKIM Works
- Your mail server generates a cryptographic hash of specified email headers and body.
- The hash is encrypted with your private DKIM key and added as a header.
- The receiving server retrieves your public key from DNS.
- It decrypts the signature and verifies the hash matches the message.
- If they match, DKIM passes — confirming authenticity.
Unlike SPF, DKIM signatures survive forwarding because they travel with the message. DKIM also verifies message integrity — if the content is altered in transit, the signature breaks.
DMARC – Domain-based Message Authentication, Reporting, and Conformance
DMARC builds on SPF and DKIM. It requires that the visible From: header domain aligns with the domain that passed SPF or DKIM — closing the spoofing loophole that SPF and DKIM alone leave open.
v=DMARC1; p=quarantine; pct=100;
rua=mailto:reports@yourdmarcexposed.com;
adkim=r; aspf=r;
DMARC Policy Options
p=)
What Happens
When to Usenone
Delivered normally — monitoring only
Initial monitoring phasequarantine
Sent to spam / junk folder
After validating legitimate sendersreject
Blocked at the server
Full enforcement after thorough testingDMARC Aggregate Reports
The rua tag specifies an address where mail providers send aggregate XML reports daily. These reports tell you every IP that sent email claiming to be from your domain, whether SPF and DKIM passed, and the overall DMARC result for each source. Your DMARC Explained parses and visualises all of this for you.
How SPF, DKIM, and DMARC Work Together
Think of email authentication as three layers:
Specifies which servers can send on your behalf.
Proves the message wasn't altered in transit.
Enforces both checks and sends you the audit trail.
For a message to pass DMARC it must pass SPF or DKIM, and the authenticated domain must align with the visible From: header. This alignment requirement is what stops attackers from using legitimate infrastructure to spoof your brand.
Why DMARC Report Monitoring Is Critical
Publishing a DMARC record is only the first step. Without monitoring the reports, you miss the most valuable part of the standard. Real-world DMARC deployments surface issues impossible to find any other way:
- Shadow IT senders: Marketing tools, CRMs, helpdesk systems that send email from your domain but aren't in your SPF record.
- Misconfigured third parties: A cloud service with broken DKIM causes transactional emails to land in spam.
- Active spoofing campaigns: Attackers impersonating your domain in targeted phishing attacks against your customers.
- Forwarding failures: Corporate email forwarding breaks SPF, causing legitimate messages to fail DMARC.
Ready to See What's Sending Email From Your Domain?
Start your free trial and get visibility into your DMARC reports within 24 hours.
Start Free Trial