How to Use DMARC to Prevent Spam and Spoofing
Combining Google Workspace’s secure-by-design architecture with Gmail’s built-in spam, phishing, and malware protections is an excellent way to protect your users from threats originating outside your domain… but what about threats by malicious actors who hijack your own domain to impersonate your users and launch email-based attacks against your customers, employees and brand?
Worse, did you know that anyone on the Internet can send email ‘from’ your domain, and they don’t even need access to your account to do it?
That’s where DMARC comes in.
Do you have a DMARC policy? 🚨
D-what? 🤔
Domain-based
Message
Authentication,
Reporting and
Conformance
Without a DMARC policy, domains that send and receive email leave the door wide-open for third parties to spoof (or impersonate) their domain to:
Launch phishing attacks 🎣
Distribute spam, malware or ransomware ☣️
Run social engineering scams against customers or employees 💸
A strong DMARC policy enables administrators to monitor, quarantine or reject delivery of messages sent using their domain by unauthorized senders.
In other words: 👏🏼 100% 👏🏼 of companies need a DMARC policy to protect their brand and domain reputation. It's so important that every Rise Digital Google Workspace client is set up with a DMARC policy from day one. ☝🏼
How does DMARC work?
DMARC works by performing two functions:
Image source: dmarc.org
First, DMARC sends you reports containing the source (servers and domains) of messages sent using your domain, and what percent of them pass or fail two important mail security protocols:
Sender Protection Framework (SPF), which specifies the servers (IP addresses) and domains (e.g. google.com) that are authorized to send email on behalf of your organization.
Domain Keys Identified Mail (DKIM), which adds a digital signature to every outgoing message, which lets receiving servers verify the message actually came from your organization, and wasn’t modified in transit.
Second, DMARC recommends what action recipient mail servers should take on messages that fail the above protocols (in other words, messages sent by unauthorized senders):
None (deliver the message)
Quarantine (deliver the message to spam)
Reject (bounce the message)
How do I enable DMARC?
The first thing to understand about implementing DMARC is that it’s a process.
To immediately reject 100% of outbound messages that fail DMARC (in other words, fail SPF and DKIM) risks interrupting delivery of business-critical mail sent by your organization’s users and systems every day.
Therefore, we recommend Google Workspace admins take a gradual approach to introducing, then strengthening, their DMARC policy - analyzing the results and monitoring for adverse impacts every step of the way.
Here’s how:
Implement SPF and DKIM for authorized senders.
Your first step is to ensure your organization has implemented SPF and DKIM for mail sent by your domain’s users and other authorized senders (such as your website or email marketing platform.
DMARC instructs mail servers how to handle messages that do not pass SPF or DKIM, so it’s important you ensure they’re enabled, first.
Create a dedicated email address to collect DMARC reports
Once your DMARC policy is in place, you’ll receive reports (in the form of .xml files) from recipient mail servers telling you which domains and servers are sending mail on behalf of your organization (using your domain).
Instead of flooding your own email address with DMARC reports, I recommend creating a dedicated repository in the form of a Google group.
To create your DMARC group:
Sign-in to the Google Admin Console
Navigate to Directory / Groups / Create group
Enter DMARC in Group name, enter dmarc in group email, and enter a description if desired. Do not enter a group owner, and do not check the Security label. Click next.
Set all access settings to Group Owners, except Who can post: External. Set who can join the group to Only invited users and do not allow members outside your organization. Click next, Create group, Done, See group settings, then advanced settings.
Under Posting policies, change Who can attach files to Anyone on the web.
Implement an initial (permissive, or relaxed) DMARC policy
Your DMARC policy will advise recipient mail servers how to handle messages that fail SPF or DKIM, and where to send the reports.
To avoid potential disruption to mail flow for authorized senders (including services you may have overlooked), it’s important not to to take any action on (potentially) unauthorized messages at this stage.
A good initial (permissing) DMARC policy looks like this:
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com… where p=none recommends normal delivery of messages that fail SPF or DKIM.
As you gain insight (via DMARC reports and adverse impacts reported by your users, if any) and enable SPF and DKIM for additional authorized senders, you can gradually tighten your policy to quarantine, and eventually reject, messages from unauthorized senders.
To implement your initial DMARC policy:
Sign into your domain registrar’s DNS console
Create a new TXT record as follows:
Name: _dmarcValue: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comTTL: Default (or 60 minutes, or 3600 secondsAnalyze DMARC reports
You’ll receive DMARC reports daily.
Within a few weeks, you’ll have enough data to begin analyzing your DMARC reports to understand:
What servers and domains are sending mail from your domain
What percent of messages from your domain pass DMARC (SPF and DKIM)
What servers and domains are sending messages that fail DMARC (SPF and DKIM)
An excellent tool for analyzing DMARC reports is DMARCian’s XML to Human Converter.
Based on your analysis, adjust your implementation of SPF and DKIM to ensure all authorized senders are passing these security checks (and therefore, passing DMARC).
Once you’ve used the information in DMARC reports to optimize your implementation of SPF and DKIM, with no adverse results (like outbound messages bouncing or being delivered to spam) it’s time to tighten your DMARC policy.
Quarantine some, then more, and eventually all messages from unauthorized senders
From this point forward, you’ll tighten your DMARC policy in small increments (the size of which may depend on the size, and therefore potential impact, on your organization, of potential adverse effects on mail delivery).
DMARC policy is tightened by editing the value of the DMARC record you added to your domain registrar’s DNS console.
For example:
v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc@yourdomain.com… where p=quarantine; pct=10 instructs recipient mail servers to deliver 10% of messages that fail DMARC (SPF and DKIM) to recipients’ spam folders. The remaining 90% of messages that fail DMARC will be delivered normally.
Once you’ve adjusted your DMARC policy:
Monitor for adverse impacts
After a few weeks, analyze your DMARC reports
Make adjustments to your implementation of SPF and DKIM, if needed
When no adverse effects are observed and no adjustments to SPF and DKIM are needed, gradually increase the percent of quarantined messages until it reaches 100%, repeating this cycle several times.
Reject messages from unauthorized senders
Once 100% of messages that fail DMARC are being quarantined with no adverse effects, you’re ready to take the final step: rejecting messages from unauthorized senders.
To do so, you’ll make one final edit to your DMARC record:
v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com… where p=reject instructs mail servers to reject (bounce) messages that fail DMARC - in other words, if messages aren’t being sent by authorized users or systems, they won’t get delivered.
While it is possible for recipient mail servers to override your DMARC policy, it’s rare for them to do so.
Congratulations! 🥳
Now, your organization is best protected against abuse by unauthorized senders spoofing your domain and impersonating your users.
