Skip to main content

Engineer's DNS Intelligence Report

fugro.com
18 Feb 2026, 14:25 UTC · 46.6s ·v26.20.48 · SHA-3-512: 8e89✱✱✱✱ Verify
Recon ModeRecon Mode Snapshot Re-analyze New Domain
DNS Security & Trust Posture
Risk Level: Low Risk
3 protocols configured, 5 not configured, 1 unavailable on provider Why we go beyond letter grades
Suggested Scanner Configuration Medium Confidence
Based on 8 historical scans of this domain
Parameter Current Suggested Severity Rationale
timeout_seconds 5s 8s low Average scan duration is 39.5s, suggesting DNS responses are slow for this domain. Increasing timeout from 5s to 8s prevents premature resolution failures.
RFC 8767
Suggestions require explicit approval before applying. No automatic changes will be made.
Email Spoofing
Protected
Brand Impersonation
Not Setup
DNS Tampering
Unsigned
Certificate Control
Open
Configured
SPF, DMARC (reject), DKIM
Not Configured
MTA-STS, TLS-RPT, BIMI, DNSSEC, CAA
Unavailable on Provider
DANE
Priority Actions 5 total Achievable posture: Secure
Medium Enable DNSSEC

DNSSEC is not enabled for this domain. DNSSEC provides cryptographic authentication of DNS responses, preventing cache poisoning and DNS spoofing attacks.

Low Add BIMI Record

Your domain has DMARC reject — you qualify for BIMI, which displays your brand logo in receiving email clients that support it (Gmail, Apple Mail, Yahoo).

BIMI displays your verified brand logo next to your emails in supporting mail clients.
FieldValue
TypeTXT
Hostdefault._bimi.fugro.com (BIMI default record)
Valuev=BIMI1; l=https://fugro.com/brand/logo.svg
Low Add CAA Records

CAA records specify which Certificate Authorities may issue certificates for your domain, reducing the risk of unauthorized certificate issuance.

CAA constrains which CAs can issue certificates for this domain.
FieldValue
TypeCAA
Hostfugro.com (root of domain — adjust CA to match your provider)
Value0 issue "letsencrypt.org"
Low Add TLS-RPT Reporting

TLS-RPT (TLS Reporting) sends you reports about TLS connection failures when other servers try to deliver mail to your domain.

TLS-RPT sends you reports about TLS connection failures to your mail servers.
FieldValue
TypeTXT
Host_smtp._tls.fugro.com (SMTP TLS reporting record)
Valuev=TLSRPTv1; rua=mailto:tls-reports@fugro.com
Low Deploy MTA-STS

MTA-STS enforces TLS encryption for inbound mail delivery, preventing downgrade attacks on your mail transport.

MTA-STS tells sending servers to require TLS when delivering mail to your domain.
FieldValue
TypeTXT
Host_mta-sts.fugro.com (MTA-STS policy record)
Valuev=STSv1; id=fugro.com
Registrar (RDAP) OBSERVED LIVE
Key-Systems GmbH
Where domain was purchased
Email Service Provider INFERRED
Microsoft 365
Strongly Protected
Web Hosting
Unknown
Where website is hosted
DNS Hosting
Unknown
Where DNS records are edited
Email Security Methodology Can this domain be impersonated by email? No SPF and DMARC reject policy enforced

SPF Record RFC 7208 §4 Verified

Does this domain declare who may send email on its behalf? Yes
Success -all 2/10 lookups

SPF valid with strict enforcement (-all), 2/10 lookups

v=spf1 include:spf-0002cd01.pphosted.com include:_u.fugro.com._spf.smart.ondmarc.com -all
RFC 7489 §10.1: -all may cause rejection before DMARC evaluation, preventing DKIM from being checked
RFC 7208 Conformant — This SPF record conforms to the syntax and semantics defined in RFC 7208 §4.
RFC Failure Mode: Unlike DMARC (where unknown tags are silently ignored per RFC 7489 §6.3), SPF with unrecognized mechanisms produces a PermError per RFC 7208 §4.6 — the record fails loudly rather than silently.
Related CVEs: CVE-2024-7208 (multi-tenant domain spoofing), CVE-2024-7209 (shared SPF exploitation), CVE-2023-51764 (SMTP smuggling bypasses SPF)
SPF hard fail (-all): compliance-strong, but can short-circuit DMARC. RFC 7489 notes that -all can cause some receivers to reject mail during the SMTP transaction — before DKIM is checked and before DMARC can evaluate the result. A message that would pass DMARC via DKIM alignment may be rejected prematurely. For most domains, ~all + DMARC p=reject is the strongest compatible posture — it allows every authentication method (SPF, DKIM, DMARC) to be fully evaluated before a decision is made.
DMARC is set to reject — enforcement is strong. However, some receivers may still reject messages on SPF hard fail before DKIM alignment is checked. Switching to ~all + p=reject would provide the same enforcement with full DMARC compatibility.

DMARC Policy RFC 7489 §6.3 Verified

Are spoofed emails rejected or quarantined? Yes — reject policy
Success p=reject

DMARC policy reject (100%) - excellent protection

v=DMARC1; p=reject; fo=1; ri=3600; rua=mailto:d5c670da@inbox.ondmarc.com,mailto:rso-dmarc@fugro.com; ruf=mailto:d5c670da@inbox.ondmarc.com,mailto:rso-dmarc@fugro.com;
Alignment: SPF relaxed DKIM relaxed
No np= tag (DMARCbis) — non-existent subdomains inherit p= policy but adding np=reject provides explicit protection against subdomain spoofing
Forensic reporting (ruf) is configured, but most major providers do not send forensic reports. RFC 7489 §7.3 warns that forensic reports can expose PII (full message headers or bodies). Google, Microsoft, and Yahoo do not honour ruf= requests. The DMARCbis draft (draft-ietf-dmarc-dmarcbis) has formally removed ruf= from the specification. Consider removing this tag to simplify your record. RFC 7489 §7.3 — Forensic Reports
RFC 7489 Conformant — DMARC record conforms to RFC 7489 §6.3 with full enforcement.
DMARCbis (Pending): draft-ietf-dmarc-dmarcbis will elevate DMARC to Standards Track, obsolete RFC 7489, replace pct= with t= (testing flag), add np= (non-existent subdomain policy), and mandate DNS tree walk for policy discovery instead of the Public Suffix List.
Related CVEs: CVE-2024-49040 (Exchange sender spoofing), CVE-2024-7208 (multi-tenant DMARC bypass)

DKIM Records RFC 6376 §3.6 Verified

Are outbound emails cryptographically signed? Yes — verified
Found

Found DKIM records for 5 selector(s)

Mail routed through Proofpoint (security gateway) — DKIM signed by Microsoft 365 (sending platform). This is a standard enterprise architecture.
k2._domainkey MailChimp
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAv2aC2KjGKLOwTweBY5A9RpjsxaBXR9r7OAU6U8/zn92ivImI75naUujWbItRI/QmL1jy5PWGqLwoUA0b90ObWaLDc+i9MtTNmGeWO009hr20fIxhGg6XBT2kjZ1DTThopSe1nAndsupmcBwlQ5Q6LJ+ZAxLcujnPIxM0ZBLmgpkv8u6RfY4eFP8OLvdAW3oSuB0DyLDigQX4Sj8wBO4YIdQH6AAmBeOsidsKAFNFUCpc3vCxtBDR12U+cBg724l3sBkMQ8evnz6idnqxq9QAVYh8k4kJ+RP+6cqTdy7LjIm8xY/bQNpQIpGUAuDo2DjLcCDun9DAI4Q/3z+Q0o9QuQIDAQAB;
s1._domainkey SendGrid
k=rsa; t=s; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2bI0HjaP+zlFqA+QcxQOOJcwyTh3FSiOkIQNvhhKMiW8DPRxFFpLj22CDWBcWHqKLGdagi7rA5ysFjtxUBWTaQSCM/ZRwMG27xd7tON6e+JGrcx5WnlqEFQdHEO8RKrcyE9HDa5dFlUbln1BMo5a1ZZL3DcPfFBNMqJ5T3BSeN0p8uKK5FusaScABrhRF2x3AFVyLxOXRInew4+HsgAbNccyaLxeTY40UCEnn0ItQy0nkWpF2OMs1LlsZjiD4I8zGAwsmZbXXvSi98HUubn7vnfROqZwO2iQVK68PpwKVeiljXSTFi4LyUW0AScQgObg5TRlnA1YCW4/aEhnbWb4SQIDAQAB
s2._domainkey SendGrid
k=rsa; t=s; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCpLK0/kisW4TA9+NiV0y4rrtWA9XGE/MlBX/OS3Blvj3MbSR+ojyKc9RPuUtLQwPMH2L4lsZCxXyfCXgWkJa8ZH5OLc6CAAGwkIlYqL77wx4FoVGVPvNu71XvhC/9AxhbnMUe8btKNhc1J63BcGEFfa6ac0LvRoxgW/TN79lINqwIDAQAB
selector1._domainkey Microsoft 365
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2rgMnwkX9fG1TAL0BL6jyDIUseq02708dBy5e/SFfBv2Ph17xmRnKXUNiMyRxTDFP09xzsualmdppiVolvWgBpuoBq9daVtkr3zLTDPSeV1CzxPmI510wtqbKwV0p/gRyhZ1bt19vmWDs/kz2LeLr2rJ4c4ggM4KMfq1/Oqb79oGMwyyGjT1AMBqI9K7G/fY5veVmvB/nfxAX1r1FWfwgiCu05FzAWeqpkxxJ7u0Fabw89AQr727G6jqXByc5hPQGaNE7PcP57EY2NTJPKVIoAT3AIzxs0brbUDPlxfKfl2Ad1dLYAnw+MQfmfzxnW0+rmPU7kDAx9961jL9FBrKiQIDAQAB;
selector2._domainkey Microsoft 365
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz9yDdUBc/ZEiKzfDT95sEx6Fy3WDbddXm09SN2EiOZYO7M2yTeChOzPxp7FI5pFWpUtQLiAVj4gpk2DtyA49cbYhnHyxrDlOhLtMoJgl+Do8IaoRHHEFV2Vvo7XxExJmJRS8PxWDBIba7/P++EfvDV7jzReRWIy5hNpoyULDXSO3ETNpVErB73yROGGLgLxSPj/F7QbKsSFnPjZ3DK4pxzdtRxewwTdmtU3YkkYkpZacaPg/FerDvKD4yIvfxv53RAo2mqikNzyA0BPPtIRGbmnZ56eyxvcz9rK/1aCh/Qf2jFtGPysArGEesSqqjtR9csTsLuQya2ReF/UC8NfzyQIDAQAB;
RFC 6376 Conformant — DKIM keys and signatures conform to RFC 6376 §3.6 (Internet Standard).
Known Vulnerabilities: DKIM l= tag body length vulnerability (attacker appends unsigned content to signed mail), weak key exploitation (keys below 1024-bit are cryptographically breakable per RFC 6376 §3.3.3), DKIM replay attacks (re-sending legitimately signed messages at scale)

MTA-STS RFC 8461 §3 Verified

Can attackers downgrade SMTP to intercept mail? Not prevented
Warning

No MTA-STS record found

MTA-STS policy enforcement is evaluated in Mail Transport Security below.

TLS-RPT RFC 8460 §3 Verified

Will failures in TLS delivery be reported? No reporting
Warning

No TLS-RPT record found

DMARC External Reporting Authorization RFC 7489 §7.1

Are external report receivers authorized? Yes — all authorized
Success

All 1 external reporting domains properly authorized

External Domain Authorization Auth Record
inbox.ondmarc.com Authorized v=DMARC1;

DANE / TLSA Verified Recon Methodology Can mail servers establish identity without a public CA? No
RFC 7672 §3 RFC 6698 §2 Not Available

DANE not available — Proofpoint does not support inbound DANE/TLSA on its MX infrastructure

DANE not deployable on Proofpoint

Proofpoint is a security gateway with shared MX infrastructure. It does not publish per-customer TLSA records.

Recommended alternative: MTA-STS


Email Transport Security

Two mechanisms protect email in transit. DANE is the primary standard; MTA-STS is the alternative for domains that cannot deploy DNSSEC:

  • DNSSEC + DANE (RFC 7672) — Cryptographic chain of trust from DNS root to mail server certificate. Eliminates reliance on certificate authorities. No trust-on-first-use weakness. Requires DNSSEC.
  • MTA-STS (RFC 8461) — HTTPS-based policy requiring TLS for mail delivery. Works without DNSSEC but relies on CA trust and is vulnerable on first use (§10). Created for domains where “deploying DNSSEC is undesirable or impractical” (§2).
This domain has neither DANE nor MTA-STS. Since Proofpoint does not support inbound DANE, deploy MTA-STS (RFC 8461) to enforce TLS and protect against downgrade attacks.

Industry trend: Microsoft Exchange Online enforces inbound DANE with DNSSEC (GA October 2024), and providers like Proton Mail and Fastmail also support DANE. Google Workspace does not support DANE and relies on MTA-STS. Both mechanisms coexist because DANE is backward-compatible — senders skip the check if the domain isn't DNSSEC-signed (RFC 7672 §1.3).


Brand Security Can this brand be convincingly faked? Unlikely DMARC reject policy blocks email spoofing, but no BIMI brand verification and no CAA certificate restriction — visual and certificate-based brand faking remains possible

BIMI BIMI Spec Verified Warning

Is the brand identity verified and displayed in inboxes? No

No BIMI record found