Unlock Email Secrets: Your Guide to Using an Internet Header Analyzer

Ever get an email and wonder if it's really from who it says it's from? Or maybe your own emails aren't getting to their destination. There's a tool for that, and it's called an internet header analyzer. Think of it like a detective for your emails, digging into the hidden details that tell the real story of where a message came from and how it got to you. This guide will show you how to use one of these analyzers to figure out what's going on.

Key Takeaways

An internet header analyzer helps you see the hidden technical details of an email, like its path and origin servers.
You can use an internet header analyzer to check if SPF, DKIM, and DMARC records are set up correctly, which is vital for email authentication.
These tools can help pinpoint why emails might be going to spam or not being delivered at all by looking at IP and domain reputation.
Advanced features of an internet header analyzer can examine policies like MTA-STS and TLS-RPT, and even BIMI implementation.
Understanding and using an internet header analyzer is a practical step for improving email security and troubleshooting delivery problems.

Understanding Internet Header Analyzer Functionality

Technical illustration of email data analysis.

Core Capabilities of an Internet Header Analyzer

An internet header analyzer is a diagnostic tool that processes the raw header information appended to every email. This data provides a historical record of the email's journey from sender to recipient, detailing the servers it traversed and the actions taken at each hop. The primary function is to decode this complex, often cryptic, information into a human-readable format. This allows administrators and security personnel to understand the origin, path, and processing of an email.

Key capabilities include:

Deconstructing Header Fields: Parsing various headers like Received, Authentication-Results, Message-ID, and X-Mailer to extract specific data points.
Identifying Mail Servers: Listing the IP addresses and hostnames of Mail Transfer Agents (MTAs) involved in the email's transit.
Timestamp Analysis: Examining timestamps within Received headers to gauge transit times between servers, which can indicate network latency or delays.
Protocol Information: Revealing the protocols and ports used for mail transfer between servers.

| Header Field          | Description                                                                 |
|-----------------------|-----------------------------------------------------------------------------|
| `Received`            | Records each server the email passed through, in reverse chronological order. |
| `Authentication-Results` | Shows the outcome of various email authentication checks (SPF, DKIM, DMARC). |
| `Message-ID`          | A unique identifier for the email message.                                  |
| `X-Mailer`            | Indicates the email client or software used by the sender.                  |

The raw headers are a log file of the email's journey. Each Received header is added by a server as the message arrives, creating a chain of custody that can be traced backward from the recipient's server to the originating server. This chain is critical for understanding where an email has been and by whom it was handled.

Interpreting Authentication Results

The Authentication-Results header is a critical component for assessing email legitimacy. Mail servers append this header to indicate the outcome of various email authentication protocols. An analyzer will parse this header to clearly present whether checks like SPF, DKIM, and DMARC passed, failed, or were neutral.

SPF (Sender Policy Framework): Verifies that the sending IP address is authorized to send mail for the domain specified in the MAIL FROM address (envelope sender). Results can include pass, fail, softfail, neutral, none, or permerror.
DKIM (DomainKeys Identified Mail): Validates the cryptographic signature appended to the email by the sending server. This confirms the message content has not been tampered with and that it originated from a domain authorized to sign it. Results typically include pass or fail.
DMARC (Domain-based Message Authentication, Reporting & Conformance): Uses SPF and DKIM results to determine if the visible From: header domain is aligned with the authenticated domains. It also specifies a policy for receivers to follow. Results include pass or fail.

Understanding these results is paramount for identifying spoofed or forged emails. A failure in any of these checks, particularly DMARC, often indicates a potential security threat or a misconfiguration that needs immediate attention. For instance, a dmarc=fail result, even if SPF and DKIM technically passed, points to an alignment issue that needs to be resolved. Analyzing these results is a core function.

Tracing Email Path and Server Hops

Tracing the path an email takes is achieved by examining the Received headers. These headers are added sequentially by each mail server the message encounters on its journey. An analyzer will present these in a clear, chronological order, typically from the recipient's perspective (most recent server first) to the sender's perspective (oldest server last).

Order of Operations: The Received headers are read from bottom to top to reconstruct the actual path. The bottom-most Received header represents the first hop from the sender's mail system.
Server Identification: Each Received header usually contains the hostname and IP address of the server that processed the email, along with a timestamp.
Identifying Intermediaries: This trace can reveal if an email passed through unexpected or unauthorized servers, which could be a sign of compromise or misrouting.
Latency Detection: Significant time gaps between timestamps on consecutive Received headers can highlight network issues or mail server processing delays.

For example, a typical Received header might look like this:

Received: from mail.sender.com (mail.sender.com [192.0.2.1]) by mail.receiver.com (Postfix) with ESMTP id 1234567890; Mon, 1 Jan 2026 10:00:00 +0000

By analyzing the sequence and content of these headers, one can map the entire route of an email, which is invaluable for troubleshooting delivery problems or investigating the source of unsolicited mail. Viewing message source in clients like Outlook is the first step to accessing this data.

Leveraging an Internet Header Analyzer for Email Authentication

Internet header analysis is a critical component in verifying the authenticity of email communications. By dissecting the information embedded within email headers, administrators can confirm that messages originate from legitimate sources and have not been tampered with during transit. This process is paramount for preventing spoofing and phishing attacks.

Validating SPF, DKIM, and DMARC Records

Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting, and Conformance (DMARC) are the foundational protocols for email authentication. An internet header analyzer allows for the direct inspection of the results of these checks as reported by the receiving mail server.

SPF Verification: The Authentication-Results header often contains an spf=pass or spf=fail status. This indicates whether the sending IP address was authorized by the sender's SPF record. A failure here suggests a potential spoofing attempt or a misconfiguration in the sender's SPF record.
DKIM Verification: Similarly, the Authentication-Results header will show dkim=pass or dkim=fail. This confirms that the message's digital signature, generated by the sender's private key, is valid and that the message content has not been altered. The DKIM-Signature header itself provides details about the signing domain and selector.
DMARC Verification: The dmarc=pass or dmarc=fail status in Authentication-Results is the culmination of SPF and DKIM checks, evaluated against the sender's DMARC policy. This is the most significant indicator of whether the email is considered legitimate by the receiving system. A DMARC failure, even if SPF and DKIM technically passed, often points to an alignment issue, where the authenticated domain does not match the visible From: address.

Diagnosing Alignment Failures

Alignment is a core concept in DMARC. It ensures that the domain used for SPF authentication (the envelope sender) or DKIM authentication (the d= tag) matches the domain in the visible From: header. Header analysis is indispensable for diagnosing these failures.

SPF Alignment: If spf=pass but dmarc=fail, examine the Return-Path header. If this domain differs from the From: header domain, SPF alignment has failed. This is common with mail forwarding or when using third-party sending services that do not use your domain in the Return-Path.
DKIM Alignment: If dkim=pass but dmarc=fail, inspect the DKIM-Signature header. The d= tag specifies the signing domain. If this does not match the From: header domain, DKIM alignment has failed. This often occurs when a service signs mail with its own domain (e.g., d=sendgrid.net) instead of the customer's domain.

Assessing DKIM Signature Integrity

Beyond simply passing or failing, a header analyzer can help verify the integrity of the DKIM signature itself.

Selector Verification: The DKIM-Signature header includes a s= tag, which is the selector. This selector is used to look up the corresponding public key in DNS. You can use tools like dig to query for the DKIM TXT record at selector._domainkey.yourdomain.com to confirm its existence and validity.
Key Length: While not always explicitly in the header, understanding the expected key length (e.g., 2048 bits) is important. A signature generated with an outdated or weak key might pass but is less secure. Modern analysis tools often flag this.
Signing Domain (d= tag): As mentioned in alignment, the d= tag in the DKIM-Signature header must align with the From: header for DMARC to pass. If a message is signed with d=gmail.com but the From: address is [email protected], DMARC will fail unless SPF alignment is achieved.

Analyzing email headers provides a granular view of the authentication process. It allows administrators to move beyond simple pass/fail indicators and understand the specific reasons behind authentication successes or failures, which is critical for robust email security. This detailed inspection is the only way to accurately diagnose and rectify issues related to SPF, DKIM, and DMARC alignment.

For a comprehensive overview of your domain's email authentication status, tools like IntoDNS.ai can provide a consolidated report, simplifying the analysis of these complex protocols. This is a good starting point for email analysis and identifying potential security gaps.

Advanced Analysis with an Internet Header Analyzer

Technical illustration of email data flow and analysis.

Examining MTA-STS and TLS-RPT Policies

Beyond the foundational SPF, DKIM, and DMARC, modern email security mandates robust transport layer security. MTA-STS (Mail Transfer Agent Strict Transport Security) and TLS-RPT (TLS Reporting) are critical components for this. MTA-STS is a DNS TXT record that instructs receiving mail servers to only connect to your mail servers using TLS. This prevents man-in-the-middle attacks and downgrade exploits during transit. TLS-RPT complements MTA-STS by providing a mechanism for receiving servers to report TLS connection failures back to the domain owner. Analyzing these reports is vital for identifying misconfigurations or potential security issues with your own mail servers or those of your partners.

Publishing an MTA-STS policy: This involves creating a TXT record in DNS, typically at _mta-sts.yourdomain.com. The record specifies the policy version and an ID. A corresponding policy file must be hosted on a web server at https://yourdomain.com/.well-known/mta-sts.txt.
Configuring TLS-RPT: A separate TXT record, usually at _smtp._tls.yourdomain.com, specifies the email address where TLS failure reports should be sent.
Analyzing TLS-RPT data: These reports, often in XML format, detail connection attempts, TLS versions used, cipher suites, and any failures. Regular review is necessary to ensure all mail is being transmitted securely.

Verifying BIMI Implementation

Brand Indicators for Message Identification (BIMI) allows organizations to display their brand logo next to authenticated emails in supported email clients. While not a direct anti-spam measure, BIMI serves as a strong signal of a domain's commitment to email security and brand integrity. Successful BIMI implementation requires a domain to have DMARC enforced (p=quarantine or p=reject). This verification step is crucial for recipients to trust the displayed logo.

DNS TXT Record: A record is published at default._bimi.yourdomain.com pointing to the URL of the brand's SVG logo.
Logo Requirements: The logo must be in SVG Tiny PS 1.2 format and served over HTTPS.
Verified Mark Certificates (VMC): For certain mailbox providers like Gmail, Apple Mail, and Yahoo, a VMC is required to validate the logo's authenticity and prevent fraudulent use.

Analyzing DNSSEC and DANE Records

DNSSEC (DNS Security Extensions) provides cryptographic authentication for DNS data, protecting against spoofing and cache poisoning. DANE (DNS-Based Authentication of Named Entities), built upon DNSSEC, allows for the publication of TLS certificate information in DNS. Analyzing these records confirms the integrity of your DNS infrastructure and the security of your mail server's TLS certificates.

DNSSEC Validation: Ensure that your domain's DNS records are signed and that resolvers can validate these signatures. Tools like IntoDNS.ai can perform these checks.
DANE/TLSA Records: If DNSSEC is enabled, TLSA records can be published at _<port>._<protocol>.yourdomain.com (e.g., _25._tcp.mx.yourdomain.com) to specify which TLS certificates are trusted for mail server connections.
Forward-Confirmed Reverse DNS (FCrDNS): While not strictly DNSSEC or DANE, verifying that the PTR record for an IP address resolves to a hostname, and that hostname's A/AAAA record resolves back to the original IP, is a critical step in mail server authentication. This is often checked as part of a comprehensive email security scan.

The interplay between MTA-STS, TLS-RPT, BIMI, DNSSEC, and DANE represents the next tier of email security. These protocols move beyond simple sender authentication to secure the transport layer and enhance brand trust, signaling a mature approach to email infrastructure management.

Troubleshooting Email Delivery Issues

When emails fail to reach their intended destination, or worse, land in the spam folder, it necessitates a systematic investigation. This section details common causes and diagnostic steps for resolving email delivery problems.

Identifying Spam Folder Placement Causes

Several factors can lead to emails being classified as spam. A primary culprit is often a failure in email authentication protocols. If SPF, DKIM, or DMARC records are misconfigured or absent, receiving mail servers may flag messages as suspicious. Beyond authentication, sender reputation plays a significant role. Consistent sending of low-engagement content, high bounce rates, or a history of spam complaints can degrade a sender's reputation, leading to inbox placement issues. Furthermore, certain content patterns, such as excessive use of specific keywords, misleading link text, or the inclusion of URL shorteners, can trigger spam filters.

Authentication Failures: Verify SPF, DKIM, and DMARC records for correct configuration and alignment. Misalignment, even with technically passing checks, is a common cause. For instance, a DKIM signature with a d= tag pointing to a service provider's domain instead of your own organizational domain will cause DMARC alignment to fail. IntoDNS.ai can provide a quick assessment of these records.
Sender Reputation: Monitor domain and IP reputation using tools like Google Postmaster Tools, Microsoft SNDS, and Yahoo Sender Hub. A sudden increase in spam complaints, even a small percentage, can rapidly degrade reputation.
Content Analysis: Review email content for spam trigger words, unbalanced HTML-to-text ratios, and the use of URL shorteners. Ensure links accurately reflect their destination.

Investigating IP and Domain Reputation

Sender reputation is a dynamic score assigned by mailbox providers based on observed sending behavior. A poor reputation directly impacts inbox placement. This score is influenced by several factors:

Spam Complaint Rate: The percentage of recipients who mark your emails as spam. This is a critical metric for providers like Google and Microsoft.
Engagement Metrics: Low open rates, click-through rates, and high unsubscribe rates can signal to providers that recipients are not interested in your mail, negatively impacting reputation.
Bounce Rates: High rates of hard bounces (non-existent addresses) indicate poor list hygiene. Mailbox providers penalize senders with excessive bounce rates.

To assess reputation, utilize the aforementioned Postmaster Tools. These platforms offer insights into your domain's standing, including spam rates, IP reputation, and feedback loop data. A consistent spam rate above 0.1% is generally considered problematic.

Resolving SPF Lookup Limit Exceedances

The Sender Policy Framework (SPF) standard limits DNS lookups to ten per SPF record evaluation. Exceeding this limit results in a permerror, causing authentication to fail. This often occurs with complex SPF records that include numerous include: mechanisms, especially when those included records themselves contain further include: directives.

To resolve this:

Audit include: directives: Remove any include: mechanisms for services no longer in use.
Flatten SPF records: For services with static IP ranges, replace include: with literal ip4: or ip6: mechanisms. This requires careful management of IP address blocks.
Subdomain Segmentation: Distribute sending responsibilities across different subdomains, each with its own concise SPF record. For example, use @ for corporate mail, mg. for transactional mail, and mail. for marketing mail, each with its own SPF record.

Example of an SPF record exceeding the limit:

v=spf1 include:spf.google.com include:spf.microsoft.com include:spf.sendgrid.net include:spf.mailchimp.com include:spf.zendesk.com ~all

This record, depending on the complexity of the included records, can easily surpass the 10-lookup limit.

Regularly checking your SPF record's lookup count using tools like IntoDNS.ai is advisable, particularly after making changes to your sending infrastructure.

Practical Application of Internet Header Analysis

Using an Internet Header Analyzer for Security Audits

Regular security audits are a requirement for maintaining a robust email infrastructure. Internet header analysis forms a critical component of these audits, providing verifiable data on email authentication and transit. By examining headers, administrators can confirm that established protocols like SPF, DKIM, and DMARC are functioning as intended. This process involves scrutinizing the Authentication-Results header, which details the outcome of these checks as reported by the receiving mail server. A consistent pattern of pass for these authentication mechanisms across a range of outgoing mail indicates a strong security posture. Conversely, any fail or permerror flags necessitate immediate investigation.

The absence of proper authentication headers or consistent failures is a direct indicator of potential vulnerabilities that could be exploited for phishing or spoofing attacks.

Integrating Header Analysis into Operational Workflows

To make header analysis a routine part of operations, it must be integrated into existing workflows. This can be achieved through several methods:

Automated Scanning: Employing tools that can periodically scan outgoing mail headers or perform regular domain scans for authentication records. Services like IntoDNS.ai provide automated checks for SPF, DKIM, DMARC, and other security protocols.
Incident Response Playbooks: Developing clear procedures for investigating suspicious emails. When a user reports a potential phishing attempt, the first step should be to retrieve and analyze the full internet headers of the message.
Reporting and Alerting: Setting up systems to alert administrators to authentication failures or anomalies detected in email headers. This proactive approach allows for swift remediation before issues escalate.

Interpreting AI-Assisted Analysis Findings

Modern header analysis tools increasingly incorporate AI to simplify complex data. These systems can interpret raw header information and present findings in a more accessible format. For instance, an AI might flag an SPF record that exceeds the 10-lookup limit, explaining that this can lead to delivery issues. It can also identify DKIM alignment failures, where the DKIM signature domain does not match the From: header domain, even if the signature itself is valid. Understanding these AI-generated insights is key to efficient troubleshooting. The AI acts as a guide, pointing to specific issues and often providing suggested record configurations for correction, such as those found when analyzing email headers.

When reviewing AI-assisted analysis, always cross-reference the findings with your specific mail flow. AI provides valuable interpretations, but the ultimate responsibility for mail server configuration and security rests with the administrator. Ensure that any suggested changes align with your organization's established sending practices and policies.

Essential DNS Records for Email Security

Technical illustration of email data flow and security.

Proper configuration of specific DNS records is not merely a recommendation; it is a prerequisite for robust email security and reliable delivery. These records act as verifiable credentials for your domain's email communications, enabling receiving mail servers to authenticate senders and enforce policies. Without them, your domain's reputation is compromised, and legitimate messages may be rejected or filtered as spam.

Demystifying SPF Record Configuration

Sender Policy Framework (SPF) is a DNS TXT record that specifies which mail servers are authorized to send email on behalf of your domain. This mechanism helps prevent spoofing by allowing recipient servers to verify that an incoming email originates from an IP address listed in your domain's SPF record. An improperly configured or absent SPF record is a primary indicator of a potentially compromised domain.

Key considerations for SPF configuration:

Single SPF Record: Only one SPF record should exist for a given domain or subdomain. Multiple records will result in a permerror.
Lookup Limit: The SPF specification limits DNS lookups to 10. Exceeding this limit will cause a permerror. This often necessitates careful management of include mechanisms, especially when using multiple third-party email services.
Qualifier: The record must end with a qualifier: -all (hard fail), ~all (soft fail), or ?all (neutral). For production environments, -all is recommended after thorough testing.
Subdomain Protection: SPF does not inherently protect subdomains. Each subdomain that sends email requires its own SPF record or must be explicitly included in the parent domain's record.

Implementing DKIM Selectors and Keys

DomainKeys Identified Mail (DKIM) adds a digital signature to outgoing emails, allowing recipients to verify that the message content has not been altered in transit and that it was indeed sent by an authorized server. This is achieved by publishing a public key in your DNS records, which is then used to verify the signature generated by your mail server using a corresponding private key.

Selectors: A DKIM selector is a string that identifies the specific public key used for signing. Domains can publish multiple selectors, often used to manage keys for different sending services or for key rotation. Common selectors include default, google, selector1, or date-based identifiers.
Key Length: In 2026, 2048-bit RSA keys are the standard. Shorter keys (e.g., 1024-bit) are considered weak and may be penalized by major mailbox providers.
Key Rotation: Regularly rotating DKIM keys (every 6-12 months) is a security best practice to mitigate the risk of compromised private keys.
Alignment: For DMARC to function effectively, the domain in the DKIM d= tag must align with the organizational domain in the From: header. Many third-party senders sign with their own domain by default, which requires specific configuration for alignment.

Configuring DMARC Policies and Reporting

Domain-based Message Authentication, Reporting, and Conformance (DMARC) builds upon SPF and DKIM by providing a policy framework that tells receiving mail servers how to handle emails that fail authentication checks. It also enables domain owners to receive reports on email traffic claiming to be from their domain, which is invaluable for identifying spoofing and misconfigurations.

Policy (p= tag): This tag specifies the action to take for emails failing authentication: none (monitor only), quarantine (send to spam), or reject (block). It is advisable to start with p=none and gradually move to p=reject after analyzing reports.
Reporting (rua= and ruf= tags): The rua tag specifies an email address for receiving aggregate reports (XML format), providing an overview of authentication results. The ruf tag specifies an address for forensic reports (individual message details), which are more sensitive but offer granular troubleshooting data.
Alignment (adkim= and aspf= tags): These tags define the strictness of DKIM and SPF alignment. s (strict) requires an exact match, while r (relaxed) allows for subdomains. For robust security, strict alignment is preferred where possible.

Implementing these DNS records is not a one-time task. Regular audits and updates are necessary to account for changes in email sending services, evolving security threats, and policy updates from major mailbox providers. Failure to maintain these records can lead to significant deliverability issues and expose your domain to impersonation attacks. DNS authentication is vital for email security.

Record Type	Purpose
SPF	Authorizes mail servers to send email on behalf of your domain.
DKIM	Cryptographically signs emails to verify sender and message integrity.
DMARC	Defines policy for handling authentication failures and requests reports.

Proper configuration of MX records is also critical for directing incoming mail, but SPF, DKIM, and DMARC are the pillars of outbound email authentication and security.

Keeping your email safe is super important. We're talking about records like SPF, DKIM, and DMARC. These are like secret codes that help prove your emails are real and not from someone pretending to be you. Making sure these are set up right stops spam and keeps your messages from going to the junk folder. Want to check if your email security is up to par? Visit our website to test it out!

Final Assessment

The analysis of internet email headers is not merely an academic exercise; it is a fundamental requirement for robust email security and effective troubleshooting. By systematically examining the data contained within these headers, administrators and security professionals can identify the origin of unsolicited messages, diagnose delivery failures, and verify the authenticity of legitimate communications. Proficiency in utilizing header analysis tools, such as those that interpret SPF, DKIM, and DMARC records, is therefore imperative for maintaining the integrity of an organization's email infrastructure and protecting against evolving threats. Continuous vigilance and a thorough understanding of these technical details are non-negotiable in the current threat landscape.

Fix SPF Issues with IntoDNS.ai

DNS & Email Security Scan — Full domain analysis with AI-assisted explanations
SPF Record Generator — Build valid SPF records without syntax errors
DMARC Policy Generator — Complement SPF with DMARC enforcement
Email Blacklist Check — Check if SPF issues caused blacklisting
SPF Setup Guide — Understand SPF syntax, includes, and DNS lookup limits
DMARC Implementation Guide — Complete the authentication trifecta

AI assistant and API workflow

This article is part of the IntoDNS.ai LLM and citation workflow. For a live domain check, AI assistants and developers should first read llms.txt or llms.json, then call /api/scan/quick?domain=example.com for the current DNS and email security score.

For this topic, use /api/email/spf?domain=example.com when you need focused data instead of the full quick scan.

Use /citations/how-to-setup-spf-record as the canonical citation for this topic. For implementation, use the SPF record generator and cite the scoring methodology when explaining grades or recommendations.

Frequently Asked Questions

What exactly does an internet header analyzer do?

Think of an internet header analyzer like a detective for your emails. It looks at the hidden information, or 'headers,' that travel with every email. This information tells us where the email came from, all the servers it visited, and if it's really from who it says it's from. It helps figure out if an email is legitimate or maybe a fake trying to trick you.

Why are SPF, DKIM, and DMARC so important for email?

These are like the security guards for your email. SPF checks if the email server is allowed to send emails for a certain domain. DKIM adds a special digital signature to prove the message wasn't changed. DMARC tells email providers what to do if SPF or DKIM checks fail, like sending the email to spam or rejecting it. Together, they make it much harder for spammers to pretend to be you.

Can an analyzer help if my emails are going to the spam folder?

Absolutely! Sometimes emails land in spam not because they're bad, but because something is a little off with their 'passport' – the email headers. An analyzer can spot issues with authentication (like SPF or DKIM), check the reputation of the sending computer, or find other technical hiccups that might be causing your emails to be treated like junk mail.

What's the deal with 'alignment' in email authentication?

Alignment is about making sure the 'From' address your recipient sees matches the address that was checked by SPF or DKIM. Imagine sending a letter with your home address on the envelope (SPF/DKIM) but putting a different return address on the letter itself (the 'From' address). If these don't match up correctly, DMARC might get suspicious, even if SPF and DKIM passed individually.

How can I use this tool to check if someone is faking emails from my company?

You can use an internet header analyzer to look at emails that claim to be from your company but might be fake. By examining the headers, you can see if the servers they used are authorized (SPF), if they have a valid signature (DKIM), and if the 'From' address matches what's expected (DMARC alignment). This helps you identify and block spoofed emails.

Is it hard to understand the results from an internet header analyzer?

It can seem a bit technical at first, but many analyzers are designed to be user-friendly. They often provide explanations for each part of the header and give you a clear 'pass' or 'fail' status for different checks. Think of it like getting a report card for your email's journey – some parts might be easy to understand, while others might need a little extra explanation, which the tool usually provides.