DMARC Enforcement Stops Domain Spoofing
Your subscribers, customers or partners can fall victim to different kinds of email phishing attacks where the “From” address has your company’s domain. Not only are phishing attacks dangerous for email recipients, but they also harm the reputation of the company’s domain which was spoofed.
Why do bad senders use domain spoofing?
It makes the message look credible. When somebody receives an email from the company they had a relationship with, they are more likely to open the message and act.
They can do it. The sender may never know that their domain was spoofed and misused.
Luckily, there is a mechanism to stop domain spoofing. This is where DMARC comes into play.
Why You Need DMARC
1. You get visibility.
With GlockApps DMARC Analytics, you get an explicit list of senders emailing on behalf of your domain. The monitor shows you a list of services and email volumes to help you decide whether to allow every particular service. You can identify what those services are and examine the DMARC compliance rate for legitimate sending sources.
You can see the things about your email authentication such as: DMARC, SPF, and DKIM pass/fail rate, and the number of emails sent by each source during the chosen period.
You can drill down by clicking on the number in the DMARC FAIL column.
The dashboard shows you the email disposition, DMARC/DKIM/SPF results, Header from and SPF (Return-Path) domains and the number of messages sent from each IP address.
Legitimate sending IP addresses authorized by the SPF record are shown by the green color.
The IP addresses not authorized by the SPF record are shown by the grey color.
The email disposition is determined by the DMARC policy: none, quarantine, or reject. In our example, the messages were rejected because the DMARC authentication failed.
Note that some email service providers will only authenticate by SPF, some only by DKIM, some will do both. DMARC passes when either SPF or DKIM evaluation or both pass.
SPF evaluation passes when the domain in Header From matches the domain in SPF (Return-Path domain). It is possible to use a subdomain in Return-Path.
DKIM evaluation passes when the domain in Header From matches the domain in the DKIM signature.
You have to examine the data for your legitimate sending IP addresses. Read the documentation of your email sending provider to configure SPF and DKIM in order for your messages to pass DMARC.
You can go to the Aggregate Reports dashboard to examine the data for all the domains.
On the graph, you can see the sent volume by days. It helps identify email phishing attacks like in the picture below. If you detect an unusually high number of unauthenticated messages sent from your domain one day that you didn’t send, you may assume that it could be a domain spoofing attempt.
Below the graph, you can see things such as policy, DMARC compliance, sending sources, DMARC/SPF/DKIM pass/fail, number of forwarded and unknown emails and the total number of messages sent from the domain during the chosen period.
For example, you may notice a high number of forwarded emails. Click on the number for more details. When you look at forwarded emails, you’ll see that some pass authentication, and some don’t.
The service which forwards the message changed the email in some way, maybe very slightly, but the change broke the SPF record and/or DKIM signature so the email is not authenticated.
The email receiver can apply local policy and still deliver the message when DMARC fails if it determines the message as a forwarded one.
If you notice Unknown senders, they can be:
bad senders impersonating your company;
third-party systems forwarding your emails;
legitimate senders not included in your SPF record.
It is better to investigate the issue, because everything with the DMARC FAIL result will be filtered or rejected.
2. You can protect your domain.
After you investigate your sending sources and fix authentication issues, you can switch to the Quarantine and some time later to the Reject DMARC policy. Thus, any message coming from your domain that failed DMARC will be blocked.
DMARC is a constant process of monitoring and adjusting configurations.
For more information about how DMARC reports can help you determine deliverability issues, check out this guide: How You Can Leverage the DMARC Analytics to Fix Deliverability Issues
Top 10 Questions & Answers
Question 1. Can I have more than one SPF record?
No. If you have more than one SPF record, the receivers around the world will treat your domain as if it had no SPF record.
Question 2. If I can’t add to the SPF record because of a 10-lookup limit, but I can set up DKIM, will DMARC pass?
For an email to authenticate by a DMARC, it must authenticate either via SPF or DKIM, both are fine, but not required. If you exceed the maximum lookups email will be treated as if it wasn’t authenticated by SPF. But you can enable DKIM to authenticate that email – that’s perfectly fine. Or you can use a flattened SPF record to avoid the 10-lookup limit.
Question 3. What is a flattened SPF record?
Basically, SPF record flattening is reduction of the amount of DNS lookups during an SPF validation. It is done by altering an SPF record: switching all the domains with their IP addresses. This procedure takes out the need for DNS lookups.
In technical terms, a flattened SPF record is a re-written record with collapsed netblocks using 1 total lookups/modifiers. Each SPF record is kept to less than 512 bytes to fit into a single UDP packet (assuming no other TXT records are sharing the DNS label). The GlockApps SPF Validator checks the SPF record validity and flattens the SPF record.
The use of a flattened SPF record is considered experimental and should not be done without careful monitoring. You should better save your original SPF record to a safe place before you replace it with the flattened record. By using a flattened record, the changes that come from “include” will not be applied automatically. You will have to track them yourself and manually update the record. If the flattened list is not up to date, some of the emails could fail authentication.
Question 4. What if I already have a DMARC record? Do I replace it with yours?
If there is a DMARC record published in your domain’s DNS, the GlockApps DMARC wizard will add the email addresses pointing to our service to the existing DMARC record. You have to update the DMARC record in DNS to start receiving DMARC reports in GlockApps DMARC Analytics.
Question 5. How does DMARC Analytics help me?
In addition to showing data about your email authentication, the GlockApps DMARC monitor analyzes your authentication records, detects changes, monitors your email traffic and alerts you when it sees:
drop in your DMARC compliance rate,
sudden growth of email traffic from your domain (possible domain spoofing and phishing attacks),
changes in the DKIM or SPF DNS records,
increase of DKIM or SPF authentication failures in traffic from your legitimate sources.
You can receive such notifications via email, Slack or Telegram. It is very helpful to be aware of any failures or changes in your email sending system.
Question 6. Is it possible to use different DMARC policies for the domain and subdomains?
If not specified otherwise, the DMARC policy on the top-level domain will apply to all of the subdomains.
There are two different tactics to take if you want different policies to be applied on subdomains:
Create a DMARC record for a subdomain and specify the policy level you require.
Use the sp= tag on your parent domain’s DMARC record to specify what policy level you would like your subdomains to have, rather than inheriting it from the parent domain.
For example, you can add sp=none to the parent domain’s DMARC reject policy so that none of your subdomains inherit the reject policy until you are ready to implement it. In this case, a full record example would look like the following:
v=DMARC1; p=reject; sp=none; fo=1; rua=mailto……..
The GlockApps DMARC wizard allows you to specify a different policy for subdomains while you are creating a DMARC record. The sp= tag with a policy for subdomains will be included in your DMARC record.
Question 7. I need to include many different senders to the SPF record. I crossed the 10-lookup limit. What is the solution?
There is no easy remedy. Possible actions are:
use a flattened SPF record;
separate mail streams by subdomains have separate email services for every subdomain.
Question 8. In the report, there are different columns such as SPF EVAL, SPF AUTH, DKIM EVAL, DKIM AUTH. What’s the difference?
DKIM AUTH (authentication) checks if the DKIM signature exists or not.
DKIM EVAL (evaluation) checks DMARC compliance. DKIM EVAL passes when the d= tag in the DKIM signature has the domain matching the domain in the Header FROM field or a sub-domain set up on the domain in the Header FROM field.
SPF AUTH checks if the SPF record exists and if it’s valid or not.
SPF EVAL (evaluation) checks DMARC compliance. SPF EVAL passes when the SPF domain (or Return-Path domain) matches the domain in the Header FROM field or a sub-domain set up on the domain in the Header FROM field.
DMARC passes when either DKIM EVAL or SPF EVAL or both pass.
Question 9. What do I do if I see an unfamiliar sending IP in the report?
You should be worried if you see a high number of emails sent from the IP addresses you don’t know but which are using your domain. Drill down to the sending sources and make sure SPF, DKIM and DMARC authentication passes for the messages sent by your legitimate sources. When everything is good, set the p=reject policy in your DMARC record to block any message sent from your domain which fails the DMARC compliance.
Question 10. How does DMARC determine that the message is valid if SPF passes and DKIM fails or vice versa?
DMARC only needs an email to pass either SPF or DKIM evaluation. For example, if an email passes SPF authentication but fails SPF evaluation when the domain in your Return Path is not the same as the ‘From’ domain then it doesn’t count and DMARC fails. Same with DKIM.