In a recent incident, a mid-sized company discovered that clients were receiving phishing emails appearing to come from their domain. The problem? They had not implemented SPF and DMARC records. This oversight led to unauthorized senders exploiting their domain. Fixing this issue not only restored their credibility but also required immediate action to secure their email system.
What Are SPF and DMARC Records?
What is SPF?
SPF is a DNS record that allows domain owners to specify which mail servers are permitted to send emails on their behalf. By listing the authorized IP addresses or hostnames in the SPF record, organizations aim to prevent spammers from sending messages with forged "from" addresses.
An SPF record typically looks like this:
v=spf1 include:_spf.google.com ~all
In this example, v=spf1 indicates the version of SPF. The include directive specifies another domain whose SPF record should be included, and ~all means that emails from other servers will be treated as soft fails.
What is DMARC?
DMARC builds on SPF and DKIM (DomainKeys Identified Mail) to provide domain owners with a way to protect their domain from being used in email spoofing and phishing. DMARC allows senders and recipients to determine how to handle emails that fail the SPF or DKIM checks.
A DMARC record looks like this:
v=DMARC1; p=none; rua=mailto:[email protected]
In this record, p=none indicates that there are currently no specific instructions for handling failed authentication. The rua tag specifies where to send reports about failures.
How It Actually Works
When an email is sent from a domain, the receiving mail server performs a series of checks:
- SPF Check: The server checks the SPF record of the sender's domain to see if the sending server's IP address is included in the allowed sources.
- DKIM Check: If the email is signed with DKIM, the server retrieves the public key from the sender's DNS records to verify the signature.
- DMARC Check: The server checks the DMARC record to see how to treat messages that fail the SPF or DKIM checks.
If either the SPF or DKIM check fails, the mail server looks at the DMARC policy to determine whether to reject, quarantine, or accept the email.
Failure Case Study: How a Misconfigured DMARC Led to Problems
In a concrete case, a tech startup faced serious repercussions when clients reported phishing emails that appeared to originate from their domain. Despite having an SPF record, their DMARC was misconfigured, allowing unauthorized senders to exploit it.
The symptoms included frequent spam reports, a significant dip in email engagement metrics, and a damaged reputation among users. The root cause was traced back to an incorrect DMARC setting that had p=none instead of a more robust policy. Over the following hours, action was taken to assess the problem, culminating in the following steps:
- Identified the Misconfiguration: After checking the DMARC settings via the SarangAI's DNS check tool, the team found the inadequate policy and recommended changing it to
p=quarantine.
- Updated the DNS Records: The configuration was updated to properly reflect the desired policy.
- Monitored Reports: The team set up periodic checks of the incoming DMARC reports to ensure no unauthorized sends were taking place.
- Engaged with Users: They communicated transparently with clients about the phishing incident and the steps taken to secure their email.
In total, the resolution took about 10 hours, restoring trust and reducing spam incidents dramatically.
Step-by-Step Remediation Walkthrough
Setting up SPF and DMARC records involves several steps. Follow this guide to ensure your domain is secure.
-
Access Your Domain's DNS Management Tool:
Log in to your DNS hosting provider and access the DNS settings for your domain.
-
Create or Update the SPF Record:
Include the relevant mail servers in your SPF record. For example:
v=spf1 a mx include:mailgun.org ~all
Expected Result: The SPF record is added, and the changes propagate within a few hours.
-
Publish the SPF Record:
Save the changes in your DNS management tool.
Expected Result: The record is accessible via DNS queries.
-
Create a DMARC Policy:
Add a DMARC record with a policy. A basic record might look like:
v=DMARC1; p=quarantine; rua=mailto:[email protected]
Expected Result: The DMARC record is now live.
-
Save Changes and Wait for Propagation:
Save all updates and allow time for DNS propagation.
Expected Result: Changes should be confirmed within 24 hours using a DNS checker.
-
Monitor Reports:
Configure your email server or DNS records to send DMARC reports to your specified email.
Expected Result: Begin receiving reports that detail email authentication failures.
-
Adjust Policies Based on Reports:
Analyze incoming reports to refine SPF and DMARC settings.
Expected Result: Polices can be strengthened over time based on report data.
-
Test Email Deliverability:
Use tools like the free email testing service on SarangAI to verify deliverability.
Expected Result: Emails from your domain should pass SPF and DMARC checks.
Common Mistakes
-
Not Including All Email Sources:
Incorrect: v=spf1 a ~all (misses third-party senders).
Correct: v=spf1 include:thirdparty.com ~all.
-
Setting DMARC Policy to p=none:
Incorrect: Using p=none which does not enforce any action.
Correct: Use p=quarantine or p=reject to ensure stricter control.
-
Failing to Update DNS Records After Changes:
Incorrect: Forgetting to update the SPF or DMARC records after changing email service providers.
Correct: Always update records with any changes to email infrastructure.
-
Neglecting to Monitor DMARC Reports:
Incorrect: Not reviewing DMARC reports regularly can lead to issues going unnoticed.
Correct: Regularly check reports to catch unauthorized send attempts.
-
Ignoring SPF Record Limits:
Incorrect: Exceeding the 10 DNS lookup limit in SPF records.
Correct: Combine mechanisms effectively to stay within limits.
Key Takeaways
- SPF records help define which mail servers can send emails for your domain.
- DMARC provides reporting and policy enforcement against unauthorized emails.
- Misconfigurations can lead to phishing incidents, costing time and reputation.
- Regularly review and adjust your email authentication policies.
- Utilize tools like SarangAI's DNS checker for effective setup verification.
Frequently Asked Questions
What are SPF and DMARC records?
SPF records specify which mail servers are allowed to send emails for your domain, while DMARC builds on SPF and DKIM to provide policies for handling unauthorized emails.
How can I check if my SPF and DMARC records are set up correctly?
You can use tools like SarangAI's DNS checker to verify your SPF and DMARC records and ensure they are configured correctly.
What do I need to set up SPF and DMARC records?
You need access to your domain's DNS settings, the IP addresses of your email servers, and a basic understanding of DNS record formats.
Why are SPF and DMARC important for email security?
They help protect your domain from being used in phishing attacks and spam, ensuring that emails sent from your domain are authenticated and trusted.
How often should I review my SPF and DMARC records?
You should review your SPF and DMARC records periodically, especially after any changes to your email infrastructure or when adding new services that send emails on your behalf.
