Using DMARC with Office 365 and G Suite [Q&A]

New email rules from major providers mean that businesses need to adopt the DMARC standard in order to ensure that their emails get delivered.

But while the new rules have received a good deal of publicity there hasn't been much attention paid to those not running their own mail server and relying on a third-party mail services.

We spoke to Al Iverson, industry research and community engagement lead at Valimail to discuss how businesses can use DMARC with Office 365 and G Suite.

BN: Why is using DMARC so important?

AI: DMARC is crucial because it helps protect your domain from being abused by email impersonators and phishers. By implementing DMARC policies, you can tell email receivers what to do with messages that fail authentication checks -- whether to let them through, quarantine them as spam, or reject them outright.

Without DMARC, fraudsters can easily send fake emails that appear to come from your domain, damaging your brand reputation and tricking your customers and employees. But with DMARC enforcement, you can shut down these impersonation attacks and ensure only legitimate email gets delivered.

What's more, major email providers like Yahoo and Google now require senders to implement email authentication (including DMARC) and are starting to delay or reject mail that lacks these crucial settings. So implementing DMARC has become essential not just for security, but for basic email deliverability too. The stakes are high -- if you don't set up DMARC properly, your important emails could get blocked and bounce back to you. (DMARC and email authentication themselves don’t guarantee perfect email deliverability; but you won’t get to the inbox without them.)

BN: Don't Google and Microsoft support DMARC already?

AI: Yes, Google and Microsoft support DMARC for email received by their Gmail and Outlook.com mailboxes. But the catch is, they can only perform DMARC authentication checks if the sending domain has published a DMARC policy in its DNS records.

Think of it like this -- Google and Microsoft are the nightclub bouncers checking IDs at the door. But the domain owner is the one responsible for issuing a valid form of ID in the first place. Without that, the bouncers can't verify if the sender is legit, no matter how strictly they check.

So while receivers like Google and Microsoft have fully embraced DMARC, it's still on each domain owner to actually implement it by publishing the right DNS records. Until you've done that, Gmail and Outlook can't help protect your domain -- the ball is in your court to enable that protection.

And that's precisely what a lot of folks misunderstand. They assume that using a big provider like Google Workspace or Microsoft 365 means they're automatically covered on the DMARC front. But really, those guys can only do DMARC validation for domains that have put in the work to publish a policy. No policy, no enforcement -- simple as that.

BN: So what do admins need to do to ensure their emails don't get marked as spam?

AI: For Microsoft 365 admins:

To maximize the chances of getting the mail delivered successfully to the inbox, the first step is making sure you've set up proper SPF, DKIM, and DMARC records in your domain's DNS settings. Microsoft has some helpful documentation on their website walking through this process.

Pay special attention to your SPF record -- make sure it includes all the Microsoft 365 servers and third-party senders that need to send mail on behalf of your domain. It's a common mistake to leave out a legitimate sender and accidentally get their messages blocked.

You'll also need to configure DKIM signing for your domain through the Microsoft 365 admin center. This involves generating a public-private key pair and publishing the public key in your DNS records. Again, Microsoft's docs outline the necessary steps.

Lastly, publish a DMARC policy specifying what receivers should do with non-authenticated messages -- start with 'none' while you're testing things out, then ramp up to 'quarantine' and eventually 'reject' to block spoofed mail.

For Google Workspace admins:

The advice for Google Workspace admins is pretty similar. First off, make sure your SPF record is squared away and lists all authorized senders, including Google's servers. Google Workspace lets you generate your SPF record right in the admin console.

Next up, enable DKIM signing for your domain, which you can also do through the Google admin interface. It will walk you through generating a key pair and provide the DNS record you need to add for the public key.

Finally, publish that DMARC record to turn on enforcement. Follow the same 'none' to 'quarantine' to 'reject' progression to avoid disrupting legitimate mail.

One extra tip for Google folks -- check out Google's Postmaster Tools, which give you visibility into your domain's email delivery health and reputation. It can help alert you to authentication issues before they cause major deliverability problems.

BN: Are there special considerations for things like bulk mailing lists?

AI: Absolutely -- bulk senders face some unique challenges when it comes to DMARC compliance. If you're sending mass email campaigns to large lists, there are a few key things to keep in mind.

First off, you need to be extra careful about staying on top of your email hygiene and avoiding anything that could get you flagged as spam. That means religiously maintaining clean lists, promptly removing bounces and unsubscribes, and steering clear of any deceptive practices.

On the technical side, when you're sending through an email service provider (ESP) you need to ensure your authentication records designate that ESP as a valid sender. Usually you do this by adding their IP addresses to your SPF record and configuring DKIM with their tools.

You’ll also need to be aware of 'alignment,' which refers to making sure that the domain or subdomain configured in your SPF or DKIM authentication (or both) matches the domain used in the from address for your ESP-sent mail. Most ESPs help you configure authentication with 'alignment' in mind, but check with them to be sure.

Another thing to watch out for is your DMARC policy settings. If you go straight to 'p=reject' without first analyzing your aggregate reports, you could inadvertently block legitimate bulk mail along with the bad stuff. Always start at 'p=none' and study your DMARC data before cranking up enforcement.

BN: What tips do you have for spotting potentially fraudulent activity on mail accounts?

AI: There are a few common red flags that can point to email fraud. Here are some things to look out for:

1. Sender domain looks suspicious. Scammers often register domains that are just slightly misspelled versions of real brand domains -- think amaz0n.com instead of amazon.com. If the sender domain looks off, that's a major warning sign.
2. Subject line instills undue urgency or panic. 'YOUR ACCOUNT WILL BE CLOSED,' 'Update payment now to avoid fees,' etc. Creating a false sense of emergency is a typical phishing tactic to fluster you into hasty action.
3. Generic salutations. Fraudsters often scrape a name from somewhere and drop it into a template, leading to awkward greetings like 'Dear Kevin Smith' instead of just 'Hi Kevin'. Legit companies usually go with the latter.
4. Poor grammar/spelling. The best phishers are getting more sophisticated, but a lot of them still make sloppy grammatical and spelling mistakes that give them away. If you notice these errors, proceed with extreme caution.
5. Mismatched 'from' name and address. Sometimes the display name will say something like 'Microsoft Support' but the actual email address is from a random domain. That's an obvious sign of impersonation.
6. Suspicious links/attachments. If you hover over a hyperlink in the message, check where the URL actually points to. And never open attachments unless you're absolutely sure the sender is legit -- they could contain malware.
7. A friend or known colleague with a name you recognize, but they're contacting you from an unexpected email account, different from the one they typically use. Your CEO isn't going to email you from a Yahoo account to ask you for your cell phone number or payment details.

One last tip -- if you're ever in doubt about a message, contact the supposed sender through a different channel to verify it. Don't trust any contact info provided in the suspicious email itself. Go directly to the source.

Image credit: jpkirakun/depositphotos.com