DMARC p=reject for companies: how to stop email sent in your name

Email has no built-in proof of who sent it. A message can carry From: direktorius@pavyzdys.lt without ever passing through that company's mail server, and the receiver cannot tell unless the domain owner publishes the rules. SPF, DKIM and DMARC are those rules: three DNS records that cost nothing.

Below: the three records, the exact values for the two providers that handled mail for about half of the domains in our sample, and a rollout order that does not block your own invoices.

SPF, DKIM and DMARC in plain words

SPF is a TXT record that lists the servers allowed to send mail with your domain in the envelope address, the record receivers use to verify that mail "is from a known, designated source of mail for that domain" (Microsoft's wording). It ends with a rule for everyone else: -all (hard fail, Microsoft's recommendation) or ~all (soft fail, Google's recommendation).

DKIM is a signature. Your provider signs each outgoing message with a private key; the public key sits in DNS under a selector such as selector1._domainkey or google._domainkey. If the message was altered or never signed, DKIM fails.

DMARC ties both to the address people see. RFC 7489, which defined it in March 2015, stores the owner's preferences "as DNS TXT records in subdomains named "_dmarc"". A message passes if SPF or DKIM passes and the domain that passed aligns with the From header; it fails only when both fail.

The record also names where receivers send aggregate reports (rua), typically once a day, which is how you learn who is sending in your name.

The three policies

RFC 7489 section 6.3 defines the p tag with three values:

Two more tags matter: pct, the "percentage of messages from the Domain Owner's mail stream to which the DMARC policy is to be applied", default 100; and sp, a separate policy for subdomains, which otherwise inherit the parent record. The alignment tags adkim and aspf default to relaxed (r).

The RFC Editor now lists RFC 9989 (Proposed Standard, May 2026), together with the reporting documents RFC 9990 and RFC 9991, as the documents that obsolete it.

What Lithuanian company domains publish

On 2026-10-24 we read the public DNS of 890 Lithuanian company domains from our own prospect lists (method in our study of Lithuanian company websites). The sample leans towards established manufacturing, logistics, wholesale and service firms; it is not representative of Lithuanian companies.

The first two rows together: 682 of 890 domains (76.6 %) have no enforcing policy, while SPF was present on 866 (97.3 %); the first step is almost universal, the last one rare. Mail for 378 domains (42.5 %) is handled by Microsoft 365 and for 76 (8.5 %) by Google Workspace, so the examples below cover those two.

The five-step rollout

Both providers document the same order. Microsoft's page: "The goal is to get to a p=reject DMARC policy for all of your custom domains and subdomains, but you need to test and verify along the way to prevent destination email systems from rejecting good mail because of unintentional DMARC failures."

1. Inventory every sender. The mail provider, the invoicing system, the CRM, the newsletter tool, the website form, the scanner. Each must pass SPF or DKIM in an aligned way. Microsoft recommends a separate subdomain for services you do not control, such as bulk mail.

1. Publish one SPF record. Only one SPF record is allowed per domain; Microsoft notes that several records make SPF return a permanent error (permerror). Microsoft 365 only: v=spf1 include:spf.protection.outlook.com -all. Google Workspace only: v=spf1 include:_spf.google.com ~all. Microsoft states that more than 10 DNS lookups makes SPF fail permanently and Google that a record can hold up to 10 include: tags, so keep the list short.

1. Turn on DKIM for each sender. Microsoft 365: two CNAME records, selector1._domainkey and selector2._domainkey, pointing to the targets shown on the DKIM tab of Email authentication settings in the Defender portal, then enable signing there. Google Workspace: Apps, Google Workspace, Gmail, Authenticate email; generate a 2048-bit key if your domain provider supports it (otherwise 1024-bit), add the TXT record at google._domainkey at your domain provider, then Start authentication; Google says it can take up to 48 hours to work. Every third-party sender must either sign with your domain or use your domain in the envelope address, or it fails alignment once you enforce; Microsoft's troubleshooting table lists both fixes.

1. Publish DMARC with p=none and a report address. Google asks you to allow 48 hours after setting up SPF and DKIM before setting up DMARC; both providers recommend a dedicated mailbox or group for reports. The aggregate reports list every IP address that sent in your name and whether it passed; Microsoft suggests reviewing them weekly during deployment and monthly once stable. Recognised senders that fail are configuration work; unrecognised senders are the reason you are doing this.

1. Move to quarantine, then reject, using pct. Once legitimate senders pass, set p=quarantine. Microsoft suggests widening in steps of pct=10, pct=25, pct=50, pct=75 and pct=100, then the same for p=reject, starting with low-volume subdomains and "saving the parent domain for last".

The records, line by line

pavyzdys.lt is a placeholder; use your own domain and report mailbox.

The last row is for parked domains: Microsoft recommends v=DMARC1; p=reject; and SPF v=spf1 -all for registered domains that "no one on the internet should expect to receive mail from". Neither Gmail nor Microsoft 365 sends forensic (ruf) reports, so the aggregate rua address is what matters.

How to check your own domain

Look up the TXT record at _dmarc.yourdomain.lt, for example with nslookup -type=TXT _dmarc.yourdomain.lt. No record, or p=none, means a forged message from your domain is delivered like any other. Then read the -all or ~all at the end of your SPF record and confirm in your provider's console that DKIM signing is on.

These checks read public DNS only; nothing is sent to or tested on your servers.

Email authentication is one layer on the Tideline page, next to PHP supported versions in 2026 and the wider picture in cybersecurity for companies in the age of artificial intelligence.

For a company covered by NIS2 in Lithuania, a published DMARC policy is also a fact a supervisor can read without asking; see NIS2 in Lithuania: KSIS and what companies must do.

Northwestern Tideline reads the public DNS of the domains a company names in writing, keeps the sender inventory, reads the aggregate reports monthly and proposes each policy step for a person to approve. To have your domain's records read and a rollout written down, send us the domain.

This guide describes public documentation as read on 2026-10-24 and a general procedure, not your own DNS, providers or senders.