Email authentication check

harvard.edu

This check reviews the domain's email authentication setup to help protect against spoofing and phishing.

All data is public, sourced from DNS Last checked about 1 hour ago
Needs attention

harvard.edu has email authentication in place, with important improvements still available.

Some protections are present, but tightening the policy, reporting, or sender authorization would improve resilience.

63 out of 110
0 of 4 checks passed
DMARC 37 / 50 · Optional SPF 26 / 30 · Optional BIMI 0 / 20 · Optional TLS 0 / 10 · Optional
Last checked about 1 hour ago
Compare with other domains

DMARC

Optional

Domain-based Message Authentication

37 / 50

Quarantine policy enabled

DMARC record is valid and configured correctly.

_dmarc.harvard.edu TXT
v=DMARC1; p=quarantine; sp=none; pct=100; adkim=r; aspf=r; rua=mailto:[email protected]

Score breakdown

  • DMARC record published +10
  • Syntax valid +5
  • Quarantine policy +12
  • Aggregate reporting (rua) configured and verified +10
  • Failure reporting (ruf) not configured (optional) 0 / 5

Configuration

Policy (p)
quarantine
DKIM alignment (adkim)
Relaxed (r)
SPF alignment (aspf)
Relaxed (r)
Subdomain policy (sp)
none

Reporting (RUA / RUF)

Aggregate reports Passed
mailto:[email protected]
External domain verification successful
Failure reports Optional
Not configured
Optional failure reporting is not configured
Record uses tags removed by RFC 9989
RFC 9989 (May 2026) removed the pct tag. Use t=y for staged rollouts instead.

SPF

Optional

Sender Policy Framework

26 / 30

SPF record is valid

SPF record is valid and complies with RFC 7208.

harvard.edu TXT
v=spf1 include:%{i}._ip.%{h}._ehlo.%{d}._spf.vali.email include:spf.mailjet.com ~all

Score breakdown

  • SPF record published +10
  • Syntax valid +5
  • Soft fail policy (~all) +6
  • No configuration warnings +5

Configuration

Default policy
~all (soft fail)
DNS lookups
2 / 10 max
Void lookups
0 / 2 max
Syntax check
OK

DNS lookup detail

Each mechanism that may trigger a DNS query at delivery time.

1 include: %{i}._ip.%{h}._ehlo.%{d}._spf.vali.email Macro

Dynamic SPF macro - counts as 1 potential lookup when evaluated at delivery time

SPF macro variables

%{i} = sender IP address, %{h} = HELO/EHLO domain, %{d} = current domain

This mechanism uses SPF macros that are expanded when an email is received. The actual domain queried depends on the sender's IP address and other connection details.

2 include: spf.mailjet.com Valid

SPF record found

v=spf1 ip4:87.253.232.0/21 ip4:185.189.236.0/22 ip4:185.211.120.0/22 ip4:185.250.236.0/22 ip4:45.14.148.0/22 ~all

Processed recursively per RFC 7208

Authorized IP addresses

include:spf.mailjet.com

87.253.232.0/21 185.189.236.0/22 185.211.120.0/22 185.250.236.0/22 45.14.148.0/22

BIMI

Optional

Brand Indicators for Message Identification

0 / 20

No BIMI record published

No BIMI record found for selector 'default'.

Score breakdown

  • BIMI record published (optional) 0 / 5

Configuration

Logo (l)
Not configured
Mark certificate (a)
Not configured
Selector
default
Note
SVG content is not parsed, for safety
BIMI is optional
BIMI usually matters after DMARC enforcement is working. Use it for brand display, not as a replacement for SPF or DMARC.

TLS

Optional

Transport security · MTA-STS & TLS-RPT

0 / 10

Inbound transport protection not fully configured

MTA-STS and TLS-RPT are optional, but they protect inbound mail against transport downgrade attacks and give visibility into TLS delivery failures.

Score breakdown

  • TLS-RPT record configured (optional) 0 / 5
  • MTA-STS policy configured (optional) 0 / 5

Configuration

TLS-RPT
Not configured
MTA-STS
Not configured

Transport checks

TLS-RPT (reporting) Not configured

No TLS-RPT record found.

MTA-STS (policy) Not configured

No MTA-STS record found.

Protect inbound transport

Receiver Shield helps deploy, monitor, and safely enforce MTA-STS and TLS-RPT for harvard.edu.

Start monitoring

harvard.edu has a DMARC quarantine policy, directing unauthenticated emails to spam. SPF is published with a soft fail policy (~all), flagging unauthorized senders without blocking them. A few improvements would strengthen harvard.edu's email authentication posture.

Keep harvard.edu protected automatically

This check is a snapshot. DNS records drift when providers change, teams edit records, or unauthorized changes slip in. DMARCTrust watches the same authentication layer continuously and tells you when something moves.

DMARC report processing

Aggregate and failure DMARC reports are received, parsed, and turned into sender visibility without manual XML handling.

DNS change alerts

DNS records are checked hourly on paid plans, with an email alert once a DMARC, SPF, BIMI, TLS-RPT, or MTA-STS change is confirmed on a second check.

Receiver Shield for inbound

Deploy, host, and safely enforce MTA-STS and TLS-RPT when this checker finds an inbound transport gap.

Start monitoring harvard.edu View plans First checked 9 months ago

Check another domain

Run a free email authentication check: DMARC, SPF, BIMI, TLS-RPT, and MTA-STS.

Try a popular example: google.com, amazon.com, booking.com
Explore

How other domains configure email authentication

Showing domains checked by our users. All data is from public DNS records.

Popular domains

Frequently checked

Well configured

Reject policy + valid SPF

Same policy

Also using quarantine

What we check

DMARC policy and alignment, SPF record and includes, BIMI logo and certificate, and inbound transport security with MTA-STS and TLS-RPT.

Why it matters

Healthy authentication improves delivery and blocks spoofing. Major inbox providers increasingly expect DMARC and aligned SPF or DKIM from senders.

What you get

Syntax, policy, reporting validation, include analysis, alignment interpretation, and clear setup guidance for every result.