Email spoofing is still one of the easiest ways for attackers to abuse your domain name. If you run a business, a homelab, or even just a side project - not setting up proper DNS mail records is basically leaving the front door unlocked. I've had to do this many times - and it is something every domain owner should take seriously. This post explains MX records, SPF, DKIM, and DMARC - what they do, how they work together, and what the different DMARC policies like p=none actually mean.

First - What Is Email Spoofing?

Email spoofing is when someone sends email that appears to originate from your domain - without actually having access to your mail server. Example: Attacker sends: From: support@yourdomain.com But the email was never sent from your infrastructure. Without protection, receiving servers have no reliable way to know that it wasn't. That is where SPF, DKIM and DMARC come in.

MX Records - Where Your Mail Lives

MX record - Mail Exchange - tells the world which server is allowed to receive mail for your domain. Example: 
 yourdomain.com. IN MX 10 mail.yourdomain.com.
This means:
  • Mail for yourdomain.com should go to mail.yourdomain.com
  • The number 10 is the priority - lower numbers mean higher priority in case of multiple MX records/mail servers
Important: MX records do not prevent spoofing. They only define where inbound mail should go. They are necessary - but not enough.

SPF - Who Is Allowed to Send Mail

SPF - Sender Policy Framework - is a TXT record that tells receiving mail servers: "These servers are allowed to send mail for my domain." Example: 
 yourdomain.com. IN TXT "v=spf1 mx ip4:203.0.113.10 include:_spf.google.com -all"

Breakdown

  • v=spf1 - SPF version
  • mx - Allow the servers defined in MX records
  • ip4:203.0.113.10 - Allow this specific IP
  • include:_spf.google.com - Allow Google to send on your behalf
  • -all - Fail everything else
The important part is the ending:
Mechanism Meaning
-all Hard fail - reject unauthorized senders
~all Soft fail - mark as suspicious
?all Neutral - no strict policy
For real protection, you typically want -all. But SPF alone is still not enough. ... Why? Because SPF can break when mail is forwarded.

DKIM - Cryptographic Proof Your Mail Is Legitimate

DKIM - DomainKeys Identified Mail - adds a digital signature to every outgoing email. Instead of just saying "this server is allowed to send mail" like SPF does, DKIM actually proves: "This email was authorized by my domain - and it has not been modified in transit."

How DKIM Works

When your mail server sends an email:
  • It signs the message using a private key
  • The receiving server fetches the public key from your DNS
  • The signature is verified
  • If it matches - the email is authentic
This uses public/private key cryptography. Your private key stays on your mail server. Your public key is published in DNS as a TXT record.

What a DKIM Record Looks Like

DKIM records are published under a selector. Example: 
 default._domainkey.yourdomain.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."
Breakdown:
  • default - Allows multiple DKIM keys, useful for key rotation, name depends on your configuration
  • _domainkey - Required DKIM namespace
  • v=DKIM1 - Version
  • k=rsa - Key type
  • p= - The public key
The selector is referenced in the email header like this: DKIM-Signature: s=default; d=yourdomain.com; ... This tells the receiving server which DNS record to check for verification.

Why DKIM Is Critical

With DKIM:
  • SPF checks the sending server.
  • DKIM checks the message integrity.
  • DMARC ties them together.
Without DKIM:
  • Forwarded mail often breaks SPF
  • DMARC enforcement becomes unreliable
  • Your domain is easier to abuse
DKIM survives forwarding because the signature stays with the message. That makes it extremely powerful.

How DKIM Works with DMARC

DMARC requires alignment. That means:
  • The domain in the From header
  • Must match the domain used in SPF and/or DKIM
If either SPF or DKIM passes - and aligns - DMARC can pass. But in modern deployments: You should always enable DKIM. - It dramatically increases deliverability and security.

Deployment Advice

  • Enable DKIM in your mail provider - most support it automatically
  • Use 2048-bit RSA keys
  • Rotate keys periodically
  • Do not reuse keys across different services
If you are using services like Microsoft 365, Google Workspace, Mailgun, SendGrid, etc., they will usually generate the DNS records for you. cPanel and other hosting providers often have built-in DKIM support as well. You just need to publish them correctly.

DMARC - The Policy Enforcer

DMARC - Domain-based Message Authentication, Reporting and Compliance - builds on SPF and DKIM and tells receiving servers: "If authentication fails - here is what you should do." It also gives you reporting - which is extremely valuable. A DMARC record is also a TXT record, but it must be created at: 
 _dmarc.yourdomain.com
Example DMARC record: 
 _dmarc.yourdomain.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; ruf=mailto:dmarc@yourdomain.com; fo=1"

Breakdown

  • v=DMARC1 - Version
  • p=none - Policy
  • rua= - Aggregate reports
  • ruf= - Forensic reports
  • fo=1 - Failure reporting options (1 = generate report if either SPF or DKIM fails)
There are more tags you can add for more granular control - but the above should be the minimum, additional tags include:
  • sp=none - Subdomain policy (if different from main domain)
  • adkim=r - DKIM alignment mode (relaxed)
  • aspf=r - SPF alignment mode (relaxed)
  • pct=100 - Percentage of mail to apply policy to
  • fo=0 - Failure reporting options (0 = generate report if both SPF and DKIM fail)
  • rf=afrf - Report format for forensic reports (afrf = Authentication Failure Reporting Format)
  • ri=86400 - Report interval in seconds (86400 = 24 hours)
The most important part is the p= tag - which defines the policy for what receiving servers should do with mail that fails authentication.

What Does p=none Actually Mean?

This is extremely important.
Policy What It Does Security Level
p=none Do nothing - only send reports but deliver mail Monitoring only
p=quarantine Mark failing mail as spam in recipient's inbox Medium
p=reject Reject failing mail completely Maximum
p=none is essentially protection disabled. It is useful when:
  • You are testing
  • You want to see who is sending mail on your behalf
  • You are collecting DMARC reports before enforcing policy
But if you leave it at p=none forever - attackers can still spoof you.

Look Up Your Domain Using Online Tools

You can check your current MX, SPF and DMARC records using online tools like: MXToolbox, it will show you:
  • Current MX records
  • SPF record and any issues
  • DMARC record and any issues, also if DMARC is enabled or disabled (p=none)

Recommended Deployment Strategy

If you are setting this up for the first time:
  1. Configure correct MX records
  2. Configure SPF with -all
  3. Deploy DMARC with p=none
  4. Monitor reports for 1-2 weeks
  5. Move to p=quarantine
  6. Eventually enforce p=reject
Gradual rollout prevents breaking legitimate mail flows.

Why This Matters For Me - And You

If someone spoofs your domain:
  • Your reputation gets damaged
  • Your domain can get blacklisted
  • Customers lose trust
  • Legitimate mail may start failing
Setting up SPF, MX and DMARC correctly:
  • Reduces spoofing risk
  • Improves deliverability
  • Gives visibility through reports
  • Protects your brand

Bottom Line

If SPF says: "This server can send mail." And DKIM says: "This message is authentic and unchanged." Then DMARC says: "If either fails - here is what to do." SPF + DKIM + DMARC together is what actually stops spoofing.

Final Thoughts

Email authentication is not optional anymore. If your domain does not have:
  • SPF configured properly
  • DMARC deployed
  • A plan to move beyond p=none
You are exposed. Take the 30 minutes. Configure it properly. Monitor it. Enforce it. Your future self - and your users - will thank you.