Sansan SPF, DKIM and DMARC setup, step by step

Quick answer: In Sansan, open Admin Settings > Domain Settings, register the approved sender domain and copy its account-issued DNS records. Publish the dedicated-subdomain MX and SPF TXT records plus the selector-specific DKIM TXT record. Return to Sansan and verify the domain. Then check a newly delivered message for the intended aligned DKIM signature and DMARC pass, not just a green configuration status.

This guide covers Sansan's native sender-domain authentication, not a separate SendGrid account or another Sansan product. It is a documentary guide, not a report of customer-account or DNS testing.

Before you start

You need Sansan administrator access, permission to use the sender identity and access to its authoritative DNS. Inventory every domain your team uses before enabling this feature: Sansan documents a ten-domain limit and warns that unconfigured domains cannot subsequently be used for bulk delivery. Obtain approval for this operational effect, not merely for adding DNS records. The Japanese documentation also applies the setting to digital business-card follow-up emails. Sansan's Japanese sender-domain instructions

Record the visible From domain, existing SPF policies, DKIM selectors, DNS delegations and applicable direct or inherited DMARC policy. Keep an approved before/after change record. A dedicated generated hostname is not permission to overwrite an occupied name or repoint existing mail.

Your corporate mailbox is a separate sending route. If you also use Microsoft 365, retain its authorizations and use the Microsoft 365 DMARC guide for that service rather than substituting Microsoft records for Sansan's records.

Obtain the records from the correct Sansan account

Open Admin Settings > Domain Settings, enter the Sender Domain, click Register, and review the DNS Settings record list. In the Japanese interface the corresponding labels are 管理者設定, ドメイン設定 and 配信元ドメイン. Use the exact approved domain, without an email local part.

The documented set contains:

The envelope domain and selector contain generated components. Do not copy the sample hostname, selector or key from a screenshot. The public instructions establish the record categories, not universal tenant values. Sansan's English setup instructions

The screenshot does not expose a separate MX-priority field. If your issued information leaves the numeric priority unspecified, obtain it from Sansan before publishing. Do not invent priority 10, infer it from another service or confuse the number with the exchange hostname.

Publish only the approved DNS changes

Check the MX destination before saving

An MX record affects mail routing at its owner. Compare the exact owner, numeric priority and exchange target with the approved Sansan delivery-subdomain plan. Leave the corporate domain's existing MX records untouched. Do not add an unapproved inbound destination merely because it appears in a provider example.

The expected change is at the account-issued dedicated hostname. If that hostname already supports another service, or the account asks for a different owner than expected, resolve the conflict with Sansan and your DNS owner. Do not delete a shared dependency to make verification turn green.

Keep SPF on the actual envelope owner

SPF evaluates SMTP MAIL FROM, not automatically the visible From address. Sansan describes a generated child domain for the envelope sender. Its SPF TXT belongs at that issued owner, not automatically at your apex. An SPF pass at a corporate domain does not prove authorization at a separate envelope hostname.

Publish one v=spf1 policy per evaluated owner. If a policy already exists at that exact name, reconcile approved authorizations with the administrator instead of creating a second SPF record. Preserve other legitimate senders and qualifiers; never paste over the corporate policy for convenience. The DNS-dependent SPF evaluation budget is ten terms, including nested mechanisms, not ten text includes. A redirect is ignored when an all mechanism is present. Qualifiers express authorization outcomes, not guaranteed inbox or rejection behavior. SPF specification, RFC 7208

Publish the complete DKIM public value

Keep the issued selector, signing domain, record type and complete public value together. A public key alone is not enough if it is published at the wrong selector owner. Never publish a private key. Do not reuse another account's sample or generate a replacement key without the signing service's participation.

DNS interfaces handle owner names differently. These examples illustrate mapping only; replace SELECTOR with the actual issued selector:

A DNS editor that appends the zone can otherwise create a doubled domain. Check the final fully qualified owner, not just the field you typed. Preserve existing NS delegations and selectors. If a required TXT or MX owner is already a CNAME, do not stack incompatible records on it; resolve the owner conflict before deployment. This documented Sansan route uses MX/TXT records, not CNAME flattening or HTTP proxy settings.

Verify DNS, then verify Sansan

Query the actual issued owners on the authoritative servers and a public resolver. These commands are placeholders, not real Sansan values or test results:

dig MX ISSUED-ENVELOPE-OWNER.example.com
dig TXT ISSUED-ENVELOPE-OWNER.example.com
dig TXT ISSUED-SELECTOR._domainkey.example.com

Compare the returned MX priority and target with the approved packet, the SPF value with the authorized envelope policy, and the joined DKIM TXT value with the complete issued public key. An empty answer warrants checking owner spelling, delegation, record type and DNS response status; it is not automatically a reason to keep waiting.

After DNS is correct, return to Sansan's domain screen and use Verify; the documented successful status is Active. In Japanese these are 確認 and 有効. Clicking the domain name reopens its required DNS records. Sansan allows up to 48 hours for DNS reflection, but wrong records do not become correct merely by waiting. Sansan verification and troubleshooting

Check a real message and preserve DMARC

With approval, send a controlled message to a valid test recipient through the intended production workflow. Use a recipient you control, not a whole customer list. Check each relevant sending path separately; a preview or one authenticated message does not certify every workflow.

Read authentication results generated within the actual receiving service's known processing boundary, using that service's documented treatment of externally supplied Authentication-Results. A familiar authserv-id or convenient header position alone is not trustworthy. Ignore attacker-supplied result fields. RFC 8601

Acceptance requires all of the following:

• The visible From remains the approved identity, not a rewritten provider address.
• The intended Sansan DKIM signature passes with the expected selector and signing domain.
• That signature aligns with the visible From under current adkim settings.
• The trusted receiver reports dmarc=pass for the intended From domain.
• The actual MAIL FROM and its SPF result match the route being investigated.

Relaxed alignment compares Organizational Domains; strict alignment requires exact domain equality. A generated child envelope domain can align in relaxed SPF mode but does not exactly match an apex From under aspf=s. A signature using the same domain as the visible From can satisfy strict DKIM alignment if it verifies. Do not weaken adkim, aspf, p or sp to mask an identity mismatch. A DMARC pass supplied solely by SPF does not prove your new DKIM setup works. Current DMARC specification

This guide preserves an existing direct or inherited DMARC policy; it does not deploy a new policy or report destination. For aggregate reports, compare the destination's Organizational Domain with the policy domain's Organizational Domain. A different one requires the report-generating receiver to check DNS authorization; the same Organizational Domain is excepted. This protocol check does not replace the owner's privacy/data-sharing approval. RFC 9990, section 4

Troubleshooting

Sansan remains inactive: Compare every issued owner, type and complete value with authoritative DNS. Check accidental spaces, doubled domain suffixes, duplicate policies and unsupported underscores. Escalate an unsupported DNS capability rather than inventing an alternate selector or removing a delegation.

The DKIM TXT looks split: One TXT resource record can contain multiple character strings that are joined for evaluation; that differs from multiple conflicting records. Follow your DNS provider's entry syntax and inspect the reconstructed value. Do not add literal quote characters blindly.

The provider FAQ suggests removing v=DKIM1: Sansan documents this as a troubleshooting suggestion. Preserve the current account-issued value first. If it contains that tag and verification fails, ask Sansan to confirm the required exact value for this configuration before altering it. Do not generalize this suggestion to other providers or delete unrelated DKIM tags. Sansan FAQ

SPF fails but DKIM passes: Diagnose separately. fail means the evaluated source was not authorized by that policy; verify the actual envelope owner and approved sender. temperror indicates a temporary evaluation problem such as DNS trouble; retry and investigate DNS availability. permerror requires repairing invalid syntax, duplicate policies or an exceeded evaluation budget. Do not dismiss these because aligned DKIM supplied a DMARC pass.

Gmail or @googlemail recipient-selection error: Sansan documents this error when domain authentication has not been completed. Complete the sender-domain setup and resolve verification; do not remove those recipients merely to conceal the authentication fault. Sansan troubleshooting

DNS and Sansan are correct but delivery fails: Check the delivered message or rejection details. Authentication is not an inbox guarantee; recipient filtering, reputation and content decisions remain separate. Do not bypass recipient restrictions or remove contacts just to hide a domain-authentication error.