Every few months we get the same call: an invoice never arrived. It usually did arrive, into a junk folder, and nobody knew.
Three DNS records tell the internet which mail services may send email as your domain. SPF lists the authorized sources. DKIM signs each outgoing message so a receiver can verify it. DMARC says what to do with mail that claims to be from you and fails those checks, and asks for reports on who sends under your name.
Microsoft treats them as one set: “Anything less than all of the email authentication methods results in substandard protection.” DKIM is the gap we find most often, because Microsoft documents that no DKIM signing happens for custom domains until somebody configures it.
Two complaints, one cause
One is your own mail being treated as suspicious: a receiving system cannot separate your invoicing tool from an impostor unless your domain publishes a list of who may send. The other is somebody sending mail that claims to be you. Microsoft calls email authentication a group of standards that “identify and prevent the delivery of email messages from forged senders.”
A post house in Burbank and an accounting firm in Franklin get identical treatment. The records are published per domain and checked the same way for everyone.
Let’s break it down: what each record does
SPF: the list of who may send
A TXT record in your DNS naming the mail sources authorized to send for your domain. Microsoft’s setup guidance notes that adding your domain to Microsoft 365 already required one, and that every subdomain needs its own: a record on yourcompany.com does not cover marketing.yourcompany.com.
DKIM: the signature that travels with the message
DKIM signs parts of each message with a private key and publishes the matching public key in DNS, so a receiver can verify nothing was altered in transit. In Microsoft 365 those are CNAME records. What surprises owners: mail from the onmicrosoft.com domain is signed for you, and mail from the domain on your business cards is not until somebody configures it.
DMARC: the instruction, and the report
A TXT record on the hostname _dmarc, doing two jobs. It tells receiving systems how to treat mail that fails the checks above: p=none for no instruction, p=quarantine to accept but mark, p=reject to refuse. And it asks for reports, which name every service sending under your domain, including ones nobody told you about. Microsoft describes a message as passing when SPF or DKIM passes and the sending domain lines up with the address your recipient sees.
The senders nobody remembers
Marketing platform. Invoicing tool. Payroll. Scheduling. CRM. E-signature. The copier that scans to email. The application that mails statements on the first of the month. Each sends as your domain, and each belongs on the list before you tighten anything.
Two more items from Microsoft’s guidance. Send bulk email platforms from a subdomain like marketing.yourcompany.com, so trouble there does not touch the reputation of staff mail. And for domains you own but never mail from, publish SPF and DMARC saying no mail should come from them, and no DKIM.
Roll DMARC out in three steps, not one
Microsoft recommends a gradual approach, for the reason everybody worries about: moving straight to p=reject before you know your senders gets good mail refused.
Start at p=none and read the reports. Move to p=quarantine once they stop surprising you. Move to p=reject last, beginning with a low-volume subdomain and saving your main domain for the end. Microsoft’s caution: “Go slowly and methodically deal with issues that are revealed in DMARC reporting.”
What these records will not do
- Filter the mail arriving at your inbox. That is a separate set of controls.
- Stop a lookalike domain. yourcompany-invoices.com can pass its own checks.
- Stop a free webmail account with your CEO’s name in the display field.
- Help once an account is compromised. Mail sent from inside your tenant is authenticated, because it is yours.
So they sit alongside MFA, inbound filtering and security awareness training. The business email compromise cases we see are a login problem in an email costume.
Your email authentication check
- A written list of every system that sends email as your company.
- One SPF TXT record per sending domain and subdomain, covering that list.
- DKIM configured for your custom domain, not only for onmicrosoft.com.
- A
_dmarcrecord in place, even atp=none. - Reports going to a shared mailbox somebody is on the hook for reading.
- Bulk and marketing mail moved onto a subdomain.
- Parked domains locked down with SPF and DMARC, and no DKIM.
Red flags
- Nobody can tell you where your DNS is hosted or who holds that login.
- “We have SPF, so we’re covered.” Microsoft’s setup page says SPF alone is not enough.
- A
p=rejectrecord published on day one with no monitoring period before it. - DMARC reports arriving in a former employee’s mailbox.
- Anyone promising your mail will reach the inbox. Nobody controls another company’s filter.
How TVG handles this
On the cybersecurity side our email work is described as email threat filtering, multi-factor authentication and hardened Microsoft 365 settings. Our Microsoft 365 consulting covers tenant setup, mailbox moves and deliverability fixes. Urgent issues get immediate engagement. The DNS work is the same in Burbank, greater Los Angeles, Nashville or Franklin. The sender inventory is the part we need you for: only your team knows the warehouse printer emails packing slips.
If this reads like a roadmap item rather than a ticket, that is a vCIO conversation. We do not publish managed IT prices in a blog post: plans are on our pricing page, and the rest is on services.
If you want to talk through your email setup, get in touch.
Frequently Asked Questions
Will fixing SPF, DKIM and DMARC stop our email going to spam?
It removes one common reason legitimate mail gets treated as suspicious, and it is the part you control. Nobody can promise inbox placement: the receiving company decides that, and content and sending history still count.
Don’t we already have these if we use Microsoft 365?
Partly. Microsoft documents that adding a custom domain already required an SPF record, and that onmicrosoft.com mail is DKIM signed automatically. For custom domains, no DKIM signing occurs until you configure it, and the DMARC record is created by hand.
Where do these records live?
At your domain registrar or DNS host. Microsoft notes there are no admin portals or PowerShell commands in Microsoft 365 for managing those records. So our first question is who holds that login.
What is the difference between p=none, p=quarantine and p=reject?
They are the policy you hand to receiving systems. p=none gives no instruction and is what you use while testing. p=quarantine asks that failing mail be accepted but marked, which can mean a junk folder. p=reject asks that it be refused, and Microsoft notes such messages are typically discarded.
Will turning on DMARC break our marketing emails?
That is the risk a staged rollout manages. If a platform sends as your domain and was never authorized in your records, tightening the policy exposes it. Microsoft’s guidance is explicit that some false positives are near unavoidable, so read the reports first.
Is this worth doing for a fifteen-person company?
Yes. If you invoice clients or email anyone about money, your domain is worth impersonating. The work is a sender inventory, a few DNS records and a monitoring period, and it does not scale with headcount.
Not sure what your domain is publishing right now?
We can read what your domain says about itself today, walk the sender list with you, and stage a DMARC rollout that does not put good mail at risk.
About the author
Garett Chipman - CEO, TVG Consulting
Garett Chipman is an IT executive and entrepreneur with more than 20 years of experience designing business technology solutions. He founded TVG Consulting in 2005 after holding CTO and management roles at companies including GRB Entertainment and AMG, and as CEO he oversees overall client operations, strategic technology decisions, and custom AI and automation design.