Setting up DMARC with Microsoft 365 in Japan

Microsoft 365 sends through its own infrastructure, so the domain's SPF record must authorise it, typically with the Microsoft 365 SPF include. DKIM is the step most projects miss: Microsoft 365 signs with a shared onmicrosoft.com domain by default, which does not align to your domain, so DKIM has to be enabled for your custom domain in the Microsoft admin centre, publishing the two CNAME records it provides. Only aligned SPF or DKIM counts toward DMARC, so custom-domain DKIM is not optional if you want a clean pass.

With SPF and DKIM in place, publish a DMARC record in DNS at p=none first, with a reporting address so the aggregate reports come back. Read them. Microsoft 365 mail should pass, but the reports will also reveal every other service sending as your domain: marketing platforms, helpdesk tools, HR and finance systems, and regional Japanese SaaS. That inventory is the real content of the project, and it is almost always larger than the team expects.

SPF permits only ten DNS lookups per check. Microsoft 365 alone is fine, but add several SaaS senders, each with its own SPF include, and the record quietly exceeds the limit. Once it does, SPF returns a permanent error and legitimate mail starts failing authentication. This is the single most common reason a Microsoft 365 DMARC project stops at p=none. The durable fix is to lean on DKIM for alignment and to remove the SPF limit rather than manage around it: Valimail Instant SPF, a patented method, resolves the domain to a single lookup without flattening, so the record stays valid however many senders you add.

Once every legitimate sender authenticates with alignment, move off p=none in stages. Set p=quarantine with the pct tag applied to a small share of mail, watch the reports, and raise it. When quarantine is stable, move to p=reject. Nothing about Microsoft 365 changes this staged path; the platform is simply one sender among several that all need to pass first. Most of the care goes into the sender inventory and alignment; the final policy change is the easy part.

The major mailbox providers, including Google, Yahoo, Yahoo Japan, Apple, and Microsoft itself, now require authentication from bulk senders, and Japan's credit-card security guidelines have pushed DMARC into regulated commerce. A Japanese enterprise on Microsoft 365 that never enabled custom-domain DKIM, or that quietly broke SPF with too many includes, is exposed on both fronts. Getting Microsoft 365 authenticated correctly, and keeping the SPF record healthy as the SaaS estate grows, is what an automated DMARC platform is for.

Microsoft 365 does not send DMARC failure reports, so the aggregate data alone will not reveal the owner of every internal service sending as your domain, and that owner discovery is what stalls enforcement. Valimail's Mailbox Connector reads Microsoft 365 metadata to identify those senders, complementing the recipient-side RUF+ method that names more than 5,500 sending services automatically. The same platform removes the SPF ten-lookup limit with Instant SPF, is the only FedRAMP authorized DMARC vendor, and is run by a team whose CTO chairs the BIMI working group, co-chairs the IETF DMARC group, and co-authored the ARC standard. For a Japanese Microsoft 365 estate, that is the difference between a project that reaches p=reject and one that stalls at p=none.

Authorise Microsoft 365 in your SPF record, enable DKIM for your custom domain in the Microsoft admin centre and publish the two CNAME records, then publish a DMARC record at p=none with a reporting address. Read the aggregate reports, fix any senders that fail alignment, and ramp through quarantine to p=reject.

By default Microsoft 365 signs with a shared onmicrosoft.com domain, which does not align to your domain and so does not satisfy DMARC. You have to enable DKIM for your custom domain in the admin centre and publish the CNAME records Microsoft provides, so signing aligns and passes.

SPF allows only ten DNS lookups per check. Microsoft 365 plus several SaaS senders, each with its own include, can exceed that limit, at which point SPF returns a permanent error and legitimate mail fails. Managing the record and relying on DKIM alignment is the durable fix.

Yes. Microsoft 365 is just one sender among several. Once every legitimate sender authenticates with alignment, ramp from p=none through p=quarantine with the pct tag to p=reject. The work is in the sender inventory and alignment; the final policy change is straightforward.

Yes. Major mailbox providers now require authentication from bulk senders, and Japan's credit-card security guidelines have pushed DMARC into regulated commerce. A Microsoft 365 estate without aligned DKIM or with a broken SPF record is exposed, and enforcement is the expected standard.