When your firm migrated to Microsoft 365, whoever handled the setup most likely added an SPF record and moved on. DKIM and DMARC—the two records that complete the email authentication chain—are the steps that routinely get skipped. The result: your domain can still be spoofed, and some legitimate email you send ends up in recipients' spam folders.
This checklist walks through verifying and finishing all three records in Microsoft 365 Business Premium. No advanced license required. No developer background required.
Summary: SPF, DKIM, and DMARC are DNS records that work together to prove your email is legitimate and instruct receiving servers on what to do when authentication fails. Most Microsoft 365 Business Premium tenants have SPF configured but leave DKIM and DMARC incomplete, keeping their domain vulnerable to spoofing. Finishing all three takes under an hour and improves both security and inbox deliverability.
What each record actually does
SPF — the approved senders list
An SPF record lists the mail servers authorized to send email on your domain's behalf. When a receiving server gets a message claiming to be from you, it checks whether the sending server is on that list. If not, the message fails SPF. SPF is necessary but not sufficient on its own.
DKIM — the tamper-evident seal
DKIM attaches a cryptographic signature to every outbound message. The receiving server retrieves your public key from DNS and verifies the signature. If the message was modified in transit, the signature breaks. DKIM catches tampering that SPF cannot detect.
DMARC — the policy that enforces both
DMARC tells receiving servers what to do when SPF or DKIM fails: deliver anyway, send to quarantine, or reject outright. It also sends aggregate reports to an address you designate, showing which servers are sending mail as your domain—authorized or not. Without DMARC, a failed authentication check may still result in delivery because there is no stated policy instructing the receiving server to act on the failure.
Why this matters for regulated businesses
A spoofed invoice sent from your firm's domain can trigger a fraudulent wire transfer. A spoofed message from a partner's address can redirect sensitive client documents. Both scenarios carry legal exposure. Regulators overseeing HIPAA-covered entities and financial advisers treat email security controls as part of a documented security program—and a missing or misconfigured DMARC record is a gap auditors flag. Separately, major email providers increasingly use DMARC alignment to decide whether your outbound messages reach the inbox or the spam folder.
Four-step checklist for Microsoft 365 Business Premium
Step 1: Verify your SPF record
- Use a public DNS lookup tool—MXToolbox's SPF checker is widely used—and search your domain.
- For Microsoft 365, the record must include
include:spf.protection.outlook.com. A correct minimal record looks like: v=spf1 include:spf.protection.outlook.com -all
- If any third-party service sends email on your domain's behalf—marketing platforms, billing software, scheduling tools—each needs its own
include: entry. Missing sources are the leading cause of legitimate mail failing authentication.
- The
-all suffix instructs receiving servers to reject mail from unlisted sources. A ~all (soft fail) is weaker. Once you have confirmed all sending sources are listed, update it to -all.
Step 2: Enable DKIM in the Microsoft 365 Defender portal
- Sign in at
security.microsoft.com. Navigate to Email & collaboration > Policies & rules > Threat policies > DKIM.
- Select your domain. If DKIM is not yet active, the portal shows two CNAME records you must publish in your DNS.
- Add those CNAME records at your DNS host or domain registrar. Changes typically propagate within an hour, though the process can take up to 48 hours.
- Return to the DKIM page and toggle signing on. The portal confirms when it detects the published keys.
Step 3: Publish a DMARC record
- In your DNS, add a TXT record with the host name
_dmarc, resulting in _dmarc.yourdomain.com.
- Start with a monitoring-only policy in this format:
v=DMARC1; p=none; rua=mailto:[email protected] — replace the address with a mailbox your team monitors.
p=none means no messages are blocked. The rua tag routes aggregate reports to that address from receiving servers worldwide.- After two to four weeks of reviewing reports and confirming all legitimate mail passes authentication, advance to
p=quarantine, then eventually to p=reject.
Step 4: Read your DMARC reports
- Aggregate reports arrive as XML files. Third-party services parse them into readable dashboards; some offer entry-level access at no cost to the user.
- Look for two things: sending sources you did not authorize, and any legitimate services whose messages are failing authentication.
- Once you reach
p=reject, receiving servers discard messages that fail both SPF and DKIM alignment—including forged messages from anyone impersonating your domain.
The mistake that breaks email flows
Moving to p=reject before identifying every legitimate sending source is the most common error. Any service sending on your domain's behalf that lacks an SPF entry or DKIM signature will have its messages rejected outright. Spend adequate time in p=none, resolve every legitimate failure the reports surface, and advance the policy only after confirming clean results.
If you are unsure where your firm currently stands, a dedicated team that knows your environment can audit your DNS records and full authentication posture in a single working session. The steps are procedural. The risk of leaving them incomplete is not.
ES
Elevate Solutions
Security & IT Advisory Team
Elevate Solutions' security and IT advisory team delivers managed cybersecurity (MDR/MXDR), managed IT, and compliance guidance (HIPAA, SOC 2, PCI DSS) for regulated mid-market firms across Los Angeles.
Reviewed by David Faramarzi · Founder, Elevate Solutions
