JSON Output Format for Parsed DSN Attachments in Email Verification APIs

Why DSN Attachments Matter in Email Verification

You send an email. It doesn’t land. The API says “invalid” — but you know the address is real. What’s missing?

Standard verification often stops at a basic SMTP check. But the full truth lies in the DSN (Delivery Status Notification) attachments — the post-delivery metadata dumped by SMTP servers after a message hits or fails its destination.

These attachments record delivery outcomes, bounce reasons, and routing history — details SMTP responses alone can’t convey. They’re like a flight’s black box: not just whether it landed, but why it didn’t, and what happened along the way.

Most email verification APIs ignore this data. But for those that parse it — especially in the JSON output format for parsed DSN attachments in email verification APIs — you get the full diagnostic picture. Not just “invalid,” but “bounced due to greylisting on server 192.168.1.25, retry failed after 60 minutes.”

Key takeaways

• DSN attachments contain SMTP-level metadata that standard checks often miss, revealing exact reasons for delivery failure.
• Only a subset of email verification APIs fully parse DSNs and expose their content via a structured JSON output format.
• Accessing parsed DSNs in JSON form enables deeper diagnostics, especially for bounces caused by transient issues like greylisting or rate limiting.

What Is the JSON Output Format for Parsed DSN Attachments?

The JSON output format for parsed DSN attachments is a structured, machine-readable representation of the raw DSN data extracted from email delivery failures. It translates cryptic MIME-formatted DSNs into clear key-value pairs—like status code, diagnostic code, recipient address, and delivery time—so you can automate failure analysis without parsing raw email content. This format is essential for integrating email verification results with monitoring tools, logging systems, or custom analytics pipelines.

How DSNs Are Structured in JSON

When an email fails to deliver, the bounce often includes a Delivery Status Notification (DSN) attached in MIME format. Parsing this raw content manually is error-prone and time-consuming. The JSON output format maps each DSN field to a named key, making it straightforward to read and process. For example, status_code becomes 2.1.5, diagnostic_code might be 550 5.1.1 User unknown, and recipient holds the actual email address.

This structure aligns with industry standards. The IETF’s RFC 3464, which defines DSNs, specifies the fields that should be included in bounce notifications. You can reference the full technical specification at RFC 3464. While the original format is MIME-based and not easily consumed by software, converting it to JSON enables consistent handling across systems, whether you’re using an API, parsing logs, or building a dashboard.

Why This Format Matters in Email Verification

Instead of parsing raw MIME strings in your code, JSON output lets you skip the complexity. You receive a clean, predictable structure that your application can query directly—no regex, no string slicing, no fallback logic for edge cases. This reduces errors and speeds up integration, especially when analyzing bulk delivery results.

At EmailListChecker, we output verified DSN data in this format through our verification API and bulk verification tool. It’s not just for debug logs—it powers real-time failure tracking, send rate optimization, and sender reputation monitoring. If you're building a system that needs to react to bounces, this structured output is the reliable foundation you need.

How Emaillistchecker.io Handles DSN Attachments in Its Verification API

You get structured, actionable insights from DSN (Delivery Status Notification) attachments in your email verification workflows. Emaillistchecker.io parses raw DSN MIME bodies from failed delivery attempts and converts them into a consistent JSON output, mapping fields like status, diagnostic_code, recipient, delivery_time, and original_envelope_id exactly as defined in RFC 3463 and RFC 6522. This lets you automate error analysis, improve list hygiene, and track sender reputation issues with precision.

Raw DSNs To Standardized JSON: What Happens Under the Hood

When you send emails via our API or bulk verification engine, we capture DSNs returned by recipient servers. These are not just headers — they’re full MIME messages with structured content. We parse them in real time, extracting diagnostic data while preserving original formatting and metadata.

Each parsed DSN maps to a standardized JSON schema. For example, a permanent failure like "550 5.1.1 User unknown" appears as "status": "failed" with "diagnostic_code": "550.5.1.1", and "recipient" includes the actual address that failed. Delivery timestamps are normalized. Original envelope IDs are preserved, which helps trace issues back to specific campaigns or sending sessions.

Why This Matters for Deliverability and Automation

Without structured DSN parsing, failure codes remain trapped in text logs — hard to query, analyze, or act on. With Emaillistchecker.io, you no longer need custom scripts to extract status codes or map failure reasons. The JSON output lets you filter by specific error types, correlate failures across campaigns, or feed data into monitoring dashboards.

For instance, a consistent 550 5.1.1 error against multiple addresses can signal invalidity, while repeated 554 5.7.1 (spammer-related) might point to a reputation issue. This level of detail is aligned with industry-standard practices — the IETF’s RFC 3463 defines the structure of DSNs, and RFC 6522 standardizes their MIME encoding. You can explore how this integrates with your workflow via our Verification API or Bulk Verification tool.

This level of machine-readability ensures you stay ahead of deliverability risks — whether you're cleaning a list, testing inbox placement, or debugging campaign performance. The full DSN context is available, so you know not just that an email failed, but why, where, and when.

Key Fields in the JSON Output for DSN Attachments

When parsing DSN (Delivery Status Notification) attachments via email verification APIs, the JSON output provides structured diagnostic details. Core fields include status (SMTP code like 550), diagnostic_code (vendor-specific failure reason), recipient (bounced address), delivery_time (UTC timestamp), and original_envelope_id (unique SMTP envelope ID for auditing).

Standardized DSN Field Definitions

The following fields are part of the standard DSN specification defined in RFC 3464, and are consistently used across compliant email systems.

Why This Matters for Deliverability

Using these fields correctly lets you move beyond simple "valid/invalid" labels and start diagnosing why an address failed. For instance, a status of 550 with a diagnostic code of USER_UNKNOWN means the recipient doesn't exist — clean the list. A 5xx with GREYLISTED suggests a temporary delay, not a permanent failure. This level of detail is essential for maintaining sender reputation, especially when dealing with high-velocity sends.

Real-time verification APIs, like the one at EmailListChecker’s API, return full DSN JSON payloads when available, allowing you to act on granular failure signals. You can use this data to improve your email hygiene, detect domain issues early, or even automate suppression rules based on failure patterns. For teams managing large lists, bulk processing with bulk verification enables systematic analysis of DSN outputs at scale.

Why Structured JSON Beats Raw DSN Parsing

You don’t need to re-invent the wheel every time you process a bounce. Raw DSN data comes in MIME format—nested, encoded, and tangled with headers, footers, and attachments that require full MIME decomposition before you can read anything. That’s slow, fragile, and error-prone at scale. Structured JSON transforms that mess into clean, predictable fields: status, reason, recipient, timestamp. You get instant access to the data you need without parsing the same raw content over and over. This isn’t just faster—it’s reliable.

Raw MIME Parsing Is a Maintenance Nightmare

Every time you receive a DSN, you’re essentially asking your system to un-pack a digital envelope, read the return path, check the content type, and extract embedded payloads—all in the correct order. If one header is misformatted or a charset is off, you can lose the entire message. Tools like RFC 6522 define how DSNs are structured, but real-world implementations vary. Parsing MIME manually means writing and testing custom logic, which breaks under new edge cases and scales poorly.

JSON Output Unlocks Automation and Visibility

Structured JSON doesn’t just save time—it enables integration. When bounce data arrives in a consistent format, you can plug it directly into analytics tools like Tableau, Snowflake, or custom dashboards without extra transformation layers. You can build rules that automatically flag high-risk domains, segment bounces by type (permanent vs. temporary), or feed data into a CRM to remove invalid emails. This is how real deliverability systems work—efficiently, at scale.

For example, if your email API returns a JSON response like:

{
"status": "failed",
"reason": "userunknown",
"recipient": "[email protected]",
"timestamp": "2024-04-05T10:30:00Z",
"dsn": "https://tools.ietf.org/html/rfc3463"
}

you can immediately act. No decompression, no guesswork. This is how deliverability engineers work when they’re serious about inbox placement.

At EmailListChecker.io’s verification API, every DSN response is returned in structured JSON by default. No parsing required. You can focus on the business logic—like cleaning your list, improving sender reputation, or triggering automated workflows—instead of fixing broken MIME parsers.

Using DSN JSON Output for List Hygiene and Delivery Diagnostics

You can use DSN JSON output from email verification APIs to detect and clean invalid or problematic email addresses at scale. A status of 550 with code 5.1.1 means the recipient doesn’t exist—often due to a typo. A 554 with code 5.7.1 signals spam rejection, which points to content issues or sender reputation problems. By processing these codes in bulk, you spot patterns—like repeated failures from a specific domain—and adjust your sending behavior accordingly.

Mapping DSN Codes for Proactive List Hygiene

1. Enable DSN parsing in your verification workflow. When your email sends trigger bounces, ensure the DSN (Delivery Status Notification) is captured and parsed into JSON format. This allows you to extract detailed diagnostic codes that plain text bounces miss.
2. Map code 5.1.1 (user unknown) to address typos. This code means the mailbox doesn’t exist. If you see it across 10% of addresses from a domain, check for common naming patterns—like [email protected] vs [email protected]—and correct the spelling or domain mapping. RFC 3463 defines these codes and their intended meaning.
3. Flag code 5.7.1 (spam rejection) as a reputational red flag. This indicates the message was blocked by the recipient server on content or sending reputation grounds. If multiple messages bounce with this code from the same domain, the domain might have reputation issues or your content triggers filters. Use this insight to refine your email content or pause sending to that domain.
4. Use real-time API integration to catch issues early. Integrate with a verification API that returns DSN JSON output. This lets you test addresses before sending, identify problems in advance, and avoid sending to known problematic domains. See how it works: API verification.
5. Run periodic bulk checks to maintain hygiene. Schedule monthly scans of your list using DSN diagnostics. Over time, this reveals trends—like consistent 5.7.1 failures from certain domains—so you can adjust your sending strategy or remove high-risk addresses entirely.

Identifying Patterns in Delivery Failures

When a single domain shows repeated 5.7.1 rejections, it’s often not the email content—it’s the sender’s reputation or the domain’s filtering policy. Spamhaus tracks known sources of spam and can help verify whether your IP or domain is included in public blocklists. Use this data, combined with DSN JSON output, to assess whether your sender reputation is at fault.

By treating DSN JSON output as diagnostic data—not just bounce logs—you turn delivery failures into actionable insights. You’re not just cleaning bad addresses; you’re adjusting how you send. This prevents future bounces, protects sender reputation, and improves overall deliverability.

Real-Time API Integration: How to Use the DSN JSON Output

When you trigger a real-time verification via Emaillistchecker.io’s API with DSN tracking enabled, the response includes a dsn_parsed field in JSON. If a DSN (Delivery Status Notification) is returned, this field contains the full parsed status data. You can extract the status and diagnostic_code to determine delivery outcomes—like permanent failures or temporary bounces—directly in your app, without storing raw DSNs.

How the DSN JSON Output Works

1. Enable DSN tracking in your API request by setting the track_dsn parameter to true. This ensures the receiving mail server sends back a DSN if delivery fails, which is then parsed by Emaillistchecker.io.
2. Receive the full JSON response from the API. The dsn_parsed field will contain a structured object if a DSN was sent, or null otherwise. This keeps your logic lightweight and avoids parsing raw RFC 3464-compliant messages manually.
3. Extract status and diagnostic_code from dsn_parsed. The status (e.g. 5.1.1) tells you whether the failure is permanent or transient. The diagnostic_code (like MX-LOOKUP-FAILED) gives specific insights into why delivery failed.
4. Use the data to make real-time decisions. For example, flag any address with a status starting with 5.xx.xx as invalid. Temporary failures (4.xx.xx) can be retried later or stored for follow-up.
5. Build logic that scales. Because the output is standardized JSON, you can integrate it into any backend system—queues, CRM, or email marketing platforms—without custom parsing logic.

Why This Matters in Practice

DSNs provide the most accurate signal about delivery failure. Unlike generic bounce codes, they’re standardized (per RFC 3464) and capture detailed, protocol-level diagnostics. Parsing them at scale without DSN tracking is unreliable.

Let’s say you’re sending transactional emails. You don’t want to trigger alerts for a temporary MX issue. But a 5.1.1 code with NO-MX-RECORD means the domain doesn’t exist—this address is permanently invalid. You can drop it from your list immediately via the status code.

For developers, the dsn_parsed field removes the need to implement your own DSN parsing layer. It’s already structured, validated, and returned with every relevant verification. Use it to improve deliverability, reduce bounce rates, and maintain sender reputation.

Explore how to use this in production with our real-time verification API: Emaillistchecker.io API.

Integrating DSN JSON Output with Mailchimp, SendGrid, and Klaviyo

When you connect Emaillistchecker.io to Mailchimp, SendGrid, or Klaviyo, the DSN JSON output from failed deliveries becomes actionable. You can configure automated rules that flag or remove addresses based on specific SMTP status codes—like 550 (user unknown) or 5.7.x (spam-related rejection)—keeping your lists clean and protecting sender reputation. The real-time integration turns error data into enforcement.

Turning DSN Errors into List Hygiene Action

Let’s say an email fails with a 5.7.1 (spam policy rejection) from SendGrid. Emaillistchecker.io parses that DSN into structured JSON and sends it to your connected tool. You can map that code to a “do not send” flag in Mailchimp or auto-remove the address from your SendGrid list. It’s not just about tracking failed sends—it’s about acting on them.

Many large email providers use these codes as signals for deliverability health. According to industry guidelines from the RFC 6522 on SMTP status codes, persistent 5xx errors (especially 5.7.x) are strong indicators of sending behavior that violates anti-spam policies. Using DSN JSON output to act on these warnings means you’re aligning with email ecosystem standards.

Automating Cleaner Lists and Better Deliverability

With Emaillistchecker.io’s integrations, you’re not just reacting to bounces—you’re preventing them. By setting rules that auto-flag or purge addresses after one or two 550 responses, you reduce hard bounce rates over time. This has a direct impact on sender reputation. ISPs like Gmail and Outlook track consistent hard bounce volume; high rates lead to throttling or blocking.

For example, if a 5.7.2 (content not permitted) occurs repeatedly from the same domain, you can automatically pause outreach. This protects your IP reputation and stops wasted sends. The integration handles the parsing of DSNs—no manual work, no guessing. The structured JSON output ensures your automation isn’t based on text parsing or fuzzy logic.

This level of integration is available for Mailchimp, SendGrid, and Klaviyo via Emaillistchecker.io’s official connectors. It works at scale, with real-time updates and no downtime. You verify your list once, and ongoing hygiene is handled by machine logic powered by actual error data.

Accuracy and Reliability of Parsed DSN Data

You get 98.9% accuracy on your email list, and that same precision extends to parsing DSNs—because we validate every field against RFC standards and only include clean, structured reports in the JSON output. Malformed or non-standard DSNs don't make it past our filters, so your analysis stays reliable.

• We validate all DSN fields against RFC 3464 (the standard for Delivery Status Notifications) to ensure consistency and compliance.
• Any DSN with incomplete, corrupted, or non-conforming data is flagged and excluded—no guesswork, no noise.
• Only DSNs with clear, actionable status codes (like 5xx for permanent failure or 4xx for temporary) are processed and included in the JSON output.
• We discard DSNs with ambiguous or unstandardized headers, which can otherwise skew deliverability insights.
• Each parsed DSN is cross-checked against known email infrastructure signatures to catch malformed or spoofed reports.
• The final JSON output contains only validated, structured data—no raw, unprocessed blobs.

Why Structured DSNs Matter

Raw DSNs are messy. They often contain inconsistent formatting, missing fields, or embedded HTML. If you parse them blindly, you risk false positives or misclassified bounces. That’s why we enforce structure. Only clean, verifiable DSNs make it into your reports.

The difference shows up in real results: when you use a service like our API, you’re not just getting a list of bounces—you’re getting a traceable, audit-ready log of why each email failed, formatted for reliable downstream processing.

Industry Standards Guide the Process

Standards matter. The RFC 3464 specification defines the expected structure and semantics of DSNs. We follow it exactly—not loosely, not approximately. If a DSN doesn’t meet the standard, it’s not just less useful; it’s a liability.

For reference, the IETF’s RFC 3464 is the definitive source for DSN formatting, status codes, and error reporting. Deviating from it means you’re chasing patterns that don’t reflect real-world delivery behavior.

Let’s be clear: we don’t claim to catch every edge case. But what we do deliver is a predictable, repeatable process—no surprises, no false signals. If a DSN makes it into your JSON, it’s because it passed every filter we’ve designed with real deliverability failures in mind.

What You Can’t Get from DSN Parsing Alone

You can’t rely on DSN parsing to catch invalid syntax, disposable domains, or role-based emails—because DSNs only tell you what happened after the email was sent. They don’t verify validity before delivery, miss early red flags like temporary or burner domains, and can’t confirm if an email is actually deliverable to a real inbox. For full assurance, DSNs must be paired with real-time validation and DNS checks.

Limitations of DSN-Based Logic

• DSNs only reflect post-delivery outcomes—bounces, delays, or rejections. They don’t catch malformed addresses or domains that don’t exist at all.
• You can't detect disposable email addresses using DSNs alone. These services are designed to intercept and reject mail after delivery, not prevent the send in the first place.
• Role-based emails (like admin@, support@, sales@) are often valid and accepted, but not necessarily real people. DSNs won’t tell you if the inbox is monitored, inactive, or automated—only that it received the message.

What You Need to Add for Complete Verification

• Validate syntax and domain existence with real-time DNS lookups—this catches 80%+ of invalid addresses before they ever reach the SMTP server.
• Use a service that flags disposable email domains: these are often created in bulk and don’t represent real recipients.
• Combine DSN data with inbox placement testing. A message that doesn’t bounce might still end up in spam or the trash—this is where deliverability testing helps.
• For full visibility, use a multi-layered approach: syntax check → DNS check → real-time API validation → inbox placement testing → DSN analysis.

Many verification services only offer one piece of this puzzle. But for the best results, you need all of them. Tools like bulk verification and real-time API checks use these same layers to achieve 98.9% accuracy—because no single signal is enough on its own.

Think of DSN parsing like a post-mortem: it tells you what failed, but not what could’ve been prevented. Use it as one input in a broader system—never as the only source.

Getting Started with DSN JSON Output in Your Workflow

Begin by using the 100 free verifications included with your Emaillistchecker.io account. This gives you direct access to the real-time API and lets you observe the structure of DSN responses as they come through.

Verify the Parsing Output

Check the dsn_parsed field in the API response to confirm that the DSN attachment has been correctly parsed into structured JSON. This field contains the diagnostic codes, status, and delivery context, which you can use to automate alerting or logging.

Interpret Diagnostic Codes

Use the in-app AI assistant to map raw diagnostic codes to known delivery issues. This helps bridge the gap between technical DSN messages and actionable insights, such as a blocked sender IP or a full inbox.

Keep reading

• Email Verification API & SDKs: the complete developer guide (complete guide)
• Batch Email Validation Drawbacks: Latency vs Real-Time Verification
• Integrate Email Verification into Bash Cron Jobs for Cleaner Lists
• Reduce API Call Overhead with SMTP Connection Reuse in Verification Scripts
• Setting SLOs for Email Verification API Response Latency in 2026

Ready to put this into practice? Emaillistchecker.io verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

What does a DSN attachment contain in email verification?

DSN attachments include SMTP-level delivery status data such as bounce codes, recipient details, timestamps, and error diagnostics—providing insight into why an email failed to deliver.

How is the JSON output for DSN attachments different from raw MIME?

The JSON output is structured and standardized, making it easier for systems to consume. Raw MIME requires decoding and parsing, which is complex and error-prone at scale.

Can I use Emaillistchecker.io’s DSN JSON to detect spam filters?

Yes, diagnostic codes like 5.7.1 or 5.7.7 in the JSON output can indicate that a recipient server marked your message as spam, helping you assess content and sending practices.

Does Emaillistchecker.io parse DSNs for every email verification?

No. DSN parsing only occurs when DSN data is returned by the receiving SMTP server during a delivery attempt. It is not included in every verification result.

How accurate is the DSN parsing in Emaillistchecker.io?

Accuracy is part of the overall 98.9% verification accuracy. We only process validated, RFC-compliant DSNs to ensure reliable output.

What happens if no DSN attachment is received?

The `dsn_parsed` field in the JSON response will be null. The API still returns core verification verdicts (valid, invalid, catch-all, risky) without DSN data.

Can DSN JSON data help reduce spam traps in my list?

Partially. While DSN parsing identifies delivery failures, it doesn’t detect spam traps directly. Use it alongside role account, disposable domain, and catch-all checks to clean your list.

Is DSN parsing available in the bulk verification API?

Yes, if the receiving servers return DSNs for the bulk campaign, Emaillistchecker.io parses and returns the JSON data in the response per email.

How do I map diagnostic codes to action in my system?

Use the standardized status and diagnostic code fields from the JSON output to create rules—e.g., flag status 550 with code 5.1.1 as invalid and remove from the list.

Why should I care about DSN data if I already use bounce handling?

Traditional bounce handling often logs only high-level codes. DSN parsing with structured JSON gives you granular, actionable insights into why bounces occur—useful for long-term list hygiene and sender reputation.

Does the DSN JSON output include the original message content?

No. The DSN JSON only contains delivery status metadata. It does not include the original email body, subject, or attachments.

Can I access historical DSN JSON data?

Yes, Emaillistchecker.io stores verified DSN results for 90 days. You can retrieve them through the API or dashboard for audit or troubleshooting.