Talk to An IT Expert Today - 405-253-5101
Kayak Cyber LLC

· cyber security · 5 min read

SPF, DKIM, and DMARC: The Email Settings Your IT Manager Should Check This Week

SPF, DKIM, and DMARC decide whether other mail servers trust email sent in your company's name. Here is what each does, why tightening them breaks vendor mail, and how co-managed IT splits the work.

SPF, DKIM, and DMARC decide whether other mail servers trust email sent in your company's name. Here is what each does, why tightening them breaks vendor mail, and how co-managed IT splits the work.

Anyone can type your company’s domain into the “from” line of an email. By default, nothing stops them.

Three settings let receiving mail servers check whether a message really came from you. They are SPF, DKIM, and DMARC. All three live in your domain’s DNS records. DNS (Domain Name System) is the internet’s address book, and your domain has one.

What each one does

  • SPF (Sender Policy Framework) is a published list of the servers allowed to send mail for your domain. The receiving server checks the sender against that list.
  • DKIM (DomainKeys Identified Mail) adds a digital signature to each outgoing message. The receiver checks it against a public record in your DNS to confirm your domain signed the message and nobody changed it on the way.
  • DMARC (Domain-based Message Authentication, Reporting and Conformance) tells receivers what to do when SPF and DKIM checks fail. It also sends you reports on who is sending mail as your domain.

SPF and DKIM do the checking. DMARC sets the consequence and gives you visibility.

Why the pressure increased

Google and Yahoo began enforcing SPF, DKIM, and DMARC requirements for bulk senders in February 2024. Bulk means 5,000 or more messages a day to their users. Microsoft began enforcing similar requirements for high-volume senders to Outlook.com consumer addresses in May 2025.

Most organizations send far less than that, so those rules may not apply to you directly. The settings still matter. They decide whether a criminal can send convincing mail as your company to your customers and vendors, and whether your own invoices and notifications reach the inbox or the spam folder.

Moving DMARC from none to reject

A DMARC policy has three levels:

  • p=none monitors only. Nothing is blocked, and you get reports.
  • p=quarantine sends failing mail to the spam folder.
  • p=reject tells the receiver to refuse failing mail.

Plenty of domains set p=none years ago and never moved. Reports pile up in a mailbox nobody reads, and spoofed mail keeps getting delivered.

The usual path is to publish p=none with reporting turned on and read the reports for several weeks. Fix every legitimate sender you find. Then move to quarantine, and later to reject. DMARC lets you apply the stricter policy to a percentage of mail at first, which softens the change.

The vendors that break when you tighten it

Your mail platform is only one of the systems that send email as your domain. Picture a contact center whose ticketing system sends every case update and satisfaction survey from the company’s own domain. Move to reject without adding it, and customers stop getting replies. Others to look for:

  • CRM and marketing platforms that send newsletters and sales sequences
  • contact center and ticketing systems
  • invoicing and billing systems
  • payroll and HR systems that send onboarding and benefits notices
  • online scheduling tools and customer portals
  • line-of-business applications, such as your ERP (enterprise resource planning) system
  • the copier or scanner that emails documents

Each one must be listed in your SPF record or set up to sign with DKIM using your domain. When one is missed and you move to reject, its mail stops arriving. Usually the first person to notice is a customer who never got an invoice or a support reply.

SPF also has a limit of 10 DNS lookups, and every vendor you include can use several. Adding vendor after vendor can break the record without anyone noticing.

Who does what in co-managed IT

DMARC is a good example of shared responsibility, because each side has information the other lacks.

Your internal IT team knows the vendors. They know who sends the invoices, who runs the newsletter, and which department signed up for a new survey tool last month. They are the ones who can say “yes, that one is ours.”

The MSP reads the DMARC reports. They arrive as dense XML files that nobody reads by hand, so we run them through a reporting tool. When an unfamiliar source shows up, we ask your IT manager whether they recognize it. If they do, we add it. If they do not, it is probably someone sending mail as you, which is exactly what the reports are there to catch.

The MSP also makes the DNS changes, or coordinates with whoever holds the login to your domain registrar. Write down who has that access. A surprising number of organizations cannot answer the question when a change is overdue.

A short list for this week

  • Look up your domain’s current DMARC record. A free lookup tool will show it.
  • If it says p=none, ask how long it has said that and who reads the reports.
  • List every system that sends mail as your domain, and ask each department what it uses.
  • Confirm each one is in SPF or signs with DKIM.
  • Confirm who has access to your DNS and your registrar account.

If you want a hand with any of it, our email security page covers what we set up and monitor.

How we help

Kayak Cyber provides email security layered on Microsoft 365, and the DMARC report reading and DNS work sit inside it. In a co-managed IT setup, we move the policy forward in steps, and your IT manager signs off on each sender before we tighten anything. Nobody learns about a missed vendor from an angry customer. Our managed IT services page describes the arrangement.

Call us at 405-253-5101 or schedule a discovery call to get on the calendar.

Share:
Back to Blog