Public email posture · checked 2026-09-21

linkedin.com: DMARC, SPF and MX report

What public DNS says about how linkedin.com authenticates and routes email — read the way a receiving mail server reads it, with every change recorded since 2026-09-20.

grade B · enforcing DMARCTranco rank 171 snapshot
Observed configurationPublic DNS only. Nothing here required access to linkedin.com.
DMARCp=reject
SPF~all
SPF lookups2/10
MX4
DKIM selectors1
MTA-STSno
RecordValue
MX10 mail-a.linkedin.com · 10 mail-c.linkedin.com · 10 mail-d.linkedin.com · 20 mail.linkedin.com
SPFv=spf1 ip4:199.101.162.0/25 ip4:108.174.3.0/24 ip4:108.174.6.0/24 ip4:108.174.0.0/24 ip6:2620:109:c00d:104::/64 ip6:2620:109:c006:104::/64 ip6:2620:109:c003:104::/64 ip6:2620:119:50c0:207::/64 ip4:199.101.161.130 mx mx:docusign.net ~all
DMARCv=DMARC1; p=reject; rua=mailto:d@rua.agari.com,mailto:yfy3q-9359@rua.dmarc.emailanalyst.com; ruf=mailto:d@ruf.agari.com
DKIM selectorsgoogle
MTA-STS / TLS-RPT / BIMIno / yes / yes
Providersinbound: Self-hosted or other
Nameserversdns1.p09.nsone.net, dns2.p09.nsone.net, dns3.p09.nsone.net, dns4.p09.nsone.net, ns1-42.azure-dns.com, ns2-42.azure-dns.net
Run a live DMARC checkBuild the digital twinLive tools re-query DNS now; this report is the 2026-09-21 snapshot.

What this configuration means

Each section below is shown because the observed records match its condition. The explanations are reviewed text selected by the data, not generated from it.

DMARC enforces rejection

linkedin.com publishes p=reject. Receivers that honour DMARC refuse mail using this domain in From unless SPF or DKIM aligns. This is the strongest published posture; it depends on every legitimate sender — including third-party platforms — having an aligned path, and on the aggregate reports the record requests to catch regressions.

SPF ends in soft fail

Unlisted sources produce softfail: receivers are asked to accept but mark the message. Under DMARC a softfail counts as an SPF failure, so the practical protection comes from DMARC policy rather than from ~all itself. Moving to -all is appropriate once the sender inventory is confirmed complete.

DKIM selectors are published

One selector resolves under _domainkey.linkedin.com: google. Selector names often identify the sending platform, and each represents a signing key that can produce an aligned DKIM path for DMARC — the path that survives forwarding.

No transport-security policy

linkedin.com does not publish MTA-STS, so senders negotiate TLS opportunistically and fall back to clear text if an attacker strips the upgrade. Publishing TLS-RPT first, then MTA-STS in testing mode, adds transport protection for inbound mail without risk to delivery.

BIMI record present

A BIMI record is published at default._bimi.linkedin.com. Logo display additionally requires an enforcing DMARC policy — which this domain has and, at most providers, a verified mark certificate.

Change history

No change has been observed since the first snapshot on 2026-09-20. The domain is re-checked regularly and a new entry appears here when any record above changes.

How to read this report

The grade summarizes two records only: A means an enforcing DMARC policy with SPF hard fail; B enforcing DMARC with SPF; C monitoring-only DMARC or a weak SPF qualifier; D one of SPF or DMARC missing; F neither published. It is a prioritization aid for the public control plane, not a statement about deliverability, reputation or the security of the organization behind the domain.

DMARC policy is discovered with the RFC 9989 DNS tree walk, so a subdomain with no record of its own is reported with the organizational policy it inherits. DKIM selectors are discovered from common names only; a domain may sign with selectors this check does not try. Everything on this page comes from public DNS as observed on 2026-09-21; caches and split-horizon DNS can show different values elsewhere.

If you operate linkedin.com and want a record corrected or the report removed, contact Mailybox.