Email server misconfigurations are an often-ignored gap in network security. Even companies with strong defences can have small mistakes in SPF, DKIM, or DMARC that leave them exposed to phishing, spoofing, or unauthorised email use.
But this isn’t a small problem: according to DeepStrike, 54% of all ransomware infections start with a phishing email, a reminder of how dangerous a single misconfiguration can be. The financial impact is just as serious: IBM’s 2025 Cost of a Data Breach Report found that the average global breach now costs USD 4.44 million.
Attackers often exploit these gaps to impersonate brands or intercept messages, but most issues are easy to spot and fix. Below are twelve common email server misconfigurations identified by ProtocolGuard, with clear examples and step-by-step fixes.
Table of Contents

1. Missing DKIM Record
DKIM (DomainKeys Identified Mail) ensures that outgoing emails are cryptographically signed so recipients can verify they truly came from your domain. Without a valid DKIM record, receiving servers cannot validate signatures, which makes spoofing trivial and can cause legitimate messages to fail authentication.
Typical error example:
selector1._domainkey.example.com: No TXT record found
Fix:
Generate a DKIM key pair using your mail service provider or MTA. Publish the public key as a TXT record in DNS:
selector1._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."
Use 2048-bit RSA keys and test with a DKIM validator. Verify Authentication-Results shows dkim=pass and rotate keys periodically.
2. Missing DMARC Forensic Report URI (ruf)
The DMARC policy defines how receiving servers should handle messages that fail SPF or DKIM checks. When your DMARC record lacks a forensic report address (ruf), you lose visibility into real-time spoofing attempts and detailed failure samples.
Typical error example:
_dmarc.example.com TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]"
Fix:
Add a ruf tag to collect forensic reports:
_dmarc.example.com TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1"
Use a secure mailbox to receive reports since they may include sensitive content.
3. Missing MX Record
MX records tell the world where to deliver emails for your domain. Proofpoint defines MX records as “a specialized DNS record that directs email messages to the appropriate mail servers for a domain.“
If your MX records are missing or you have an MX misconfiguration, messages will fail to reach you, or some servers will fall back to using your A record, which causes routing errors.
Typical error example:
example.com: No MX records found (fallback to A record 203.0.113.10)
Fix:
Add MX records that point to valid mail servers:
example.com MX 10 mail.example.com
mail.example.com A 203.0.113.20
Ensure each MX host supports STARTTLS and resolves correctly, and make sure you’re not carrying any SSL/TLS misconfigurations that could break secure delivery.
4. Invalid External MX
Another of the major email server misconfigurations involves mistakenly configured MX records that point to non-existent or external hosts not under our control. This can cause mail loss or interception.
Typical error example:
example.com MX 10 mx.mailer.gogle.com (NXDOMAIN)
Fix:
Correct the hostname:
example.com MX 10 mx.mailer.google.com
Verify DNS resolution and TLS certificates for each mail server. Remove old MX entries from past providers.
5. Open Relay
An open relay allows unauthenticated users to send emails through your server, and it’s a very serious security misconfiguration. Attackers exploit open relays to send spam or phishing from your IP, causing blacklisting.
Typical error example:
MAIL FROM:<[email protected]>
RCPT TO:<[email protected]>
250 OK queued for delivery
Fix:
Restrict relaying to authenticated users and local IPs only. In Postfix:
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination
Test again externally; relay attempts should return 554 Relay access denied.
6. SPF Permanent Error
SPF validates authorised mail servers. A permanent SPF error means that you probably have an SPF misconfiguration, like syntax problems or exceeding the 10 DNS lookup limit.
Typical error example:
v=spf1 include:vendor1.com include:vendor2.com include:vendor3.com include:vendor4.com include:vendor5.com include:vendor6.com include:vendor7.com include:vendor8.com include:vendor9.com include:vendor10.com include:vendor11.com -all
Fix:
Reduce lookups and consolidate includes:
v=spf1 include:_spf.google.com include:sendgrid.net ip4:198.51.100.10 ip4:198.51.100.20 -all
Validate SPF with the dig command or using online validators.
7. Overly Permissive SPF
If your SPF record ends with +all or ~all, unauthorised servers can pass or soft-fail checks, enabling spoofing.
Typical error example:
v=spf1 include:_spf.google.com +all
Fix:
Tighten restrictions using -all once testing is complete:
v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.50 -all
Ensure all legitimate senders are validated before enforcing.
8. Multiple SPF Records
Publishing multiple SPF records may be the result of a DNS misconfiguration, causing validation failures because only the first record is evaluated.
Typical error example:
v=spf1 include:_spf.google.com -all
v=spf1 include:mailchimp.com -all
Fix:
Merge all includes into one record:
v=spf1 include:_spf.google.com include:servers.mcsv.net -all
Remove redundant TXT entries after testing.
9. Weak or Missing DMARC
Without DMARC, spoofed messages can be delivered without restriction. Even p=none for too long is weak enforcement.
Typical error example:
No TXT record found at _dmarc.example.com or v=DMARC1; p=none
Fix:
Deploy a strong policy:
v=DMARC1; p=quarantine; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1
Move to p=reject once all legitimate mail passes alignment.
10. Missing DMARC Aggregate Report URI (rua)
The rua tag collects daily XML reports summarising authentication results. Missing it hides valuable insights.
Typical error example:
v=DMARC1; p=quarantine
Fix:
Add rua reporting:
v=DMARC1; p=quarantine; rua=mailto:[email protected]
Use a parser to visualise reports and track sender performance.
11. Missing CAA Record
CAA records control which SSL/TLS certificate issuer can issue certificates for your domain. Without them, any CA could issue one, increasing risks.
Typical error example:
example.com: No CAA records found
Fix:
Add a CAA entry:
example.com CAA 0 issue "letsencrypt.org"
example.com CAA 0 iodef "mailto:[email protected]"
Restrict issuance and set a contact for alerts. Also, make sure to check our SSL/TLS security guide to avoid common pitfalls.
12. SPF Soft Fail
Using ~all marks unauthorised senders as suspicious, but does not reject them. Suitable for testing, unsafe for production.
Typical error example:
v=spf1 include:_spf.google.com ~all
Fix:
After validation, switch to hard fail:
v=spf1 include:_spf.google.com -all
Monitor logs for false positives and correct failing sources.
Checking Your Domain for Common Email Server Misconfigurations
So, how can you make sure that you’re not falling into any of these email server misconfigurations?
The easiest way to test this is by using our web security scanner. Start by opening our tool (click the previous link), type your domain into the box, and hit “Scan.”
After a few seconds, you’ll get a full breakdown of your site’s security, including whether anything’s off with your email setup.
Conclusion
Email server misconfigurations are often invisible until something breaks: a phishing campaign, a blacklist, or an undelivered mail. Regularly auditing SPF, DKIM, DMARC, MX, and CAA records helps prevent these issues and protects your reputation.
ProtocolGuard automates these checks, helping identify weaknesses early and providing step-by-step guidance for remediation.

