{"id":211,"date":"2026-05-14T05:42:01","date_gmt":"2026-05-14T05:42:01","guid":{"rendered":"https:\/\/photonconsole.com\/blog\/?p=211"},"modified":"2026-05-14T05:42:03","modified_gmt":"2026-05-14T05:42:03","slug":"choosing-an-smtp-relay-8-critical-criteria-developers-must-evaluate","status":"publish","type":"post","link":"https:\/\/photonconsole.com\/blog\/choosing-an-smtp-relay-8-critical-criteria-developers-must-evaluate\/","title":{"rendered":"Choosing an SMTP Relay: 8 Critical Criteria Developers Must Evaluate"},"content":{"rendered":"\n<p>Your staging environment sends emails without a single failure. SPF and DKIM are configured. Integration tests pass. You ship to production.<\/p>\n\n\n\n<p>Then launch day arrives. OTP emails start queuing. Onboarding confirmations are delayed by four minutes. You open your SMTP dashboard and find no useful diagnostics \u2014 just a vague delivery count and a green status indicator that refuses to explain anything.<\/p>\n\n\n\n<p>Most SMTP relay evaluations focus on feature lists instead of operational behavior under production load. Developers verify DKIM support and sign up. What they do not test is how the relay behaves when 40,000 OTP emails hit the queue simultaneously \u2014 or whether the platform surfaces actionable data during an outage.<\/p>\n\n\n\n<p>The real quality of an SMTP relay is usually discovered after deployment, not during signup.<\/p>\n\n\n\n<p>This guide is a structured evaluation framework for developers, startup CTOs, and SaaS engineering teams who need an SMTP relay decision that survives production scale.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">Table of Contents<\/h2>\n\n\n\n<ol class=\"wp-block-list\">\n<li><a href=\"#quick-answer\">Quick Answer: What to Evaluate Before Choosing an SMTP Relay<\/a><\/li>\n\n\n\n<li><a href=\"#what-smtp-relay-does\">What an SMTP Relay Actually Does<\/a><\/li>\n\n\n\n<li><a href=\"#why-expensive-later\">Why SMTP Relay Decisions Become Expensive Later<\/a><\/li>\n\n\n\n<li><a href=\"#evaluation-framework\">The 8-Criterion Developer Evaluation Framework<\/a>\n<ul class=\"wp-block-list\">\n<li><a href=\"#deliverability\">Deliverability Reliability<\/a><\/li>\n\n\n\n<li><a href=\"#pricing\">Pricing Model Structure<\/a><\/li>\n\n\n\n<li><a href=\"#latency\">Delivery Latency<\/a><\/li>\n\n\n\n<li><a href=\"#observability\">Monitoring and Observability<\/a><\/li>\n\n\n\n<li><a href=\"#scalability\">Scalability Behavior<\/a><\/li>\n\n\n\n<li><a href=\"#authentication\">Authentication and Security<\/a><\/li>\n\n\n\n<li><a href=\"#developer-experience\">API and Developer Experience<\/a><\/li>\n\n\n\n<li><a href=\"#transparency\">Operational Transparency<\/a><\/li>\n<\/ul>\n<\/li>\n\n\n\n<li><a href=\"#evaluation-mistakes\">Most Common SMTP Relay Evaluation Mistakes<\/a><\/li>\n\n\n\n<li><a href=\"#shared-vs-dedicated\">Shared IP vs Dedicated IP: How to Decide<\/a><\/li>\n\n\n\n<li><a href=\"#how-to-test\">How to Test an SMTP Relay Before Committing<\/a><\/li>\n\n\n\n<li><a href=\"#reality-snapshot\">Reality Snapshot: OTP Failure During a Traffic Spike<\/a><\/li>\n\n\n\n<li><a href=\"#photonconsole\">How PhotonConsole Approaches SMTP Relay Infrastructure<\/a><\/li>\n\n\n\n<li><a href=\"#checklist\">SMTP Relay Evaluation Checklist<\/a><\/li>\n\n\n\n<li><a href=\"#key-takeaways\">Key Takeaways<\/a><\/li>\n\n\n\n<li><a href=\"#faq\">Frequently Asked Questions<\/a><\/li>\n\n\n\n<li><a href=\"#conclusion\">Conclusion<\/a><\/li>\n<\/ol>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"quick-answer\">Quick Answer: What to Evaluate Before Choosing an SMTP Relay<\/h2>\n\n\n\n<p>When choosing an SMTP relay, evaluate these eight criteria in order of operational consequence \u2014 not feature availability:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Deliverability reliability<\/strong> \u2014 inbox placement rates, ISP relationships, IP pool hygiene<\/li>\n\n\n\n<li><strong>Pricing model structure<\/strong> \u2014 subscription tiers vs pay-per-use, overage behavior, cost at 10x volume<\/li>\n\n\n\n<li><strong>Delivery latency<\/strong> \u2014 P95 and P99 latency, not averages; critical for OTP and authentication flows<\/li>\n\n\n\n<li><strong>Monitoring and observability<\/strong> \u2014 per-message event logs, bounce diagnostics, webhook reliability<\/li>\n\n\n\n<li><strong>Scalability behavior<\/strong> \u2014 queue handling under burst traffic, rate limits, retry storm management<\/li>\n\n\n\n<li><strong>Authentication support<\/strong> \u2014 SPF, DKIM, DMARC alignment, domain reputation protection<\/li>\n\n\n\n<li><strong>API and developer experience<\/strong> \u2014 error visibility, SDK quality, debugging support<\/li>\n\n\n\n<li><strong>Operational transparency<\/strong> \u2014 status page quality, incident communication, failure visibility<\/li>\n<\/ul>\n\n\n\n<p>Each criterion has an operational consequence that compounds over time. Skipping any one of them is a risk that surfaces under pressure, not during setup.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">SMTP Relay Evaluation Priority Order<\/h2>\n\n\n\n<p>When prioritization matters \u2014 and it will during incident response \u2014 use this hierarchy:<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><thead><tr><th>Priority<\/th><th>Criterion<\/th><th>Operational Consequence If Skipped<\/th><\/tr><\/thead><tbody><tr><td>1<\/td><td>Inbox Reliability<\/td><td>Undelivered email is invisible failure<\/td><\/tr><tr><td>2<\/td><td>Latency Stability<\/td><td>OTP delays convert directly to churn<\/td><\/tr><tr><td>3<\/td><td>Observability Quality<\/td><td>Incidents without logs become permanent guesswork<\/td><\/tr><tr><td>4<\/td><td>Scalability Behavior<\/td><td>Burst failures hit at the worst possible moment<\/td><\/tr><tr><td>5<\/td><td>Pricing Efficiency<\/td><td>Entry cost rarely reflects production cost<\/td><\/tr><tr><td>6<\/td><td>Developer Experience<\/td><td>Poor APIs extend every incident duration<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"what-smtp-relay-does\">What an SMTP Relay Actually Does<\/h2>\n\n\n\n<p><strong>Definition:<\/strong> An SMTP relay is infrastructure that accepts outbound email from applications, manages queuing and retries, communicates with recipient mail servers using reputation-aware sending IPs, and tracks delivery outcomes per message.<\/p>\n\n\n\n<p>Your application submits a message via SMTP credentials or an API key and receives a <code>250 OK<\/code> response. That response confirms the relay accepted the message \u2014 not that it was delivered.<\/p>\n\n\n\n<p>Actual delivery, deferral, bounce, or failure happens asynchronously \u2014 sometimes seconds later, sometimes minutes later, depending on recipient server conditions and queue depth. The relay&#8217;s responsibilities in that window include:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Queuing and retrying messages when recipient servers are temporarily unavailable<\/li>\n\n\n\n<li>Communicating with ISPs using reputation-aware sending infrastructure<\/li>\n\n\n\n<li>Classifying bounces (hard vs soft) and managing suppression lists<\/li>\n\n\n\n<li>Signing outbound messages with your domain&#8217;s DKIM key<\/li>\n\n\n\n<li>Reporting delivery events back via webhooks or log APIs<\/li>\n<\/ul>\n\n\n\n<p>This asynchronous gap between acceptance and delivery is where most SMTP reliability failures live. It is also where observability tooling either saves you or leaves you guessing.<\/p>\n\n\n\n<p>For a deeper look at the infrastructure layer, the <a href=\"https:\/\/photonconsole.com\/blog\/smtp-relay-service\/\" target=\"_blank\" rel=\"noreferrer noopener\">SMTP relay service architecture guide<\/a> covers queue systems and retry behavior in detail.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"why-expensive-later\">Why SMTP Relay Decisions Become Expensive Later<\/h2>\n\n\n\n<p>SMTP relay selection feels lightweight during onboarding. The structural cost becomes clear later \u2014 usually at the worst possible time.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Migration Difficulty<\/h3>\n\n\n\n<p>SMTP migration becomes significantly harder once reputation history, suppression lists, and delivery workflows are deeply integrated into production. Moving providers means a new IP warmup cycle \u2014 weeks of temporarily depressed inbox placement rates. Migrating webhook schemas, bounce handling logic, and suppression list formats adds engineering time that is almost always underestimated.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Deliverability Reputation Lock-In<\/h3>\n\n\n\n<p>Domain reputation accrues against specific IP pools. Switching providers does not transfer that history. For high-volume senders, re-establishing inbox placement rates after a migration can take longer than the migration itself.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing Escalation<\/h3>\n\n\n\n<p>A provider costing $15\/month at 10,000 emails may cost $400\/month at 300,000 emails \u2014 not because prices changed, but because subscription tiers are structured to extract value at scale. Always model cost at 3x and 10x volume before committing.<\/p>\n\n\n\n<p>The <a href=\"https:\/\/photonconsole.com\/blog\/pay-per-use-email-api-vs-subscription-total-cost-of-ownership-analysis-for-saas-teams\/\" target=\"_blank\" rel=\"noreferrer noopener\">total cost of ownership analysis for SaaS teams<\/a> shows exactly where subscription and pay-per-use models diverge as volume grows.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Operational Dependency<\/h3>\n\n\n\n<p>Once transactional email is live, your SMTP relay is critical infrastructure. A fast relay with opaque incident communication is still an expensive relay \u2014 because every undisclosed failure costs your team debugging time rather than recovery time.<\/p>\n\n\n\n<p><strong>Operational Reality:<\/strong> Most developers do not regret choosing an SMTP relay during onboarding. They regret it during scaling, outages, migration, and unexpected billing spikes. That delayed pain is structurally predictable \u2014 and mostly preventable.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"evaluation-framework\">The 8-Criterion Developer Evaluation Framework<\/h2>\n\n\n\n<p>Choosing an SMTP relay on feature availability alone is how teams end up rebuilding email infrastructure six months after launch. The following framework evaluates providers on operational behavior \u2014 the only thing that matters at production scale.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"deliverability\">1. Deliverability Reliability<\/h3>\n\n\n\n<p>Deliverability is the most important metric for transactional email and the hardest to verify during a free-tier trial. Authentication failures are among the most common causes of delivery problems \u2014 so before evaluating inbox placement numbers, confirm proper DKIM signing, SPF alignment, and DMARC enforcement on your sending domain.<\/p>\n\n\n\n<p>Key questions:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>What is the provider&#8217;s inbox placement rate across Gmail, Outlook, and Yahoo?<\/li>\n\n\n\n<li>Are shared IPs segmented by sender type \u2014 transactional vs marketing?<\/li>\n\n\n\n<li>What happens to your delivery when a neighbor on a shared IP is flagged for spam?<\/li>\n\n\n\n<li>How does the provider handle IP warmup for new dedicated IPs?<\/li>\n<\/ul>\n\n\n\n<p><strong>Shared IP infrastructure works \u2014 until somebody else&#8217;s sending behavior becomes your problem.<\/strong><\/p>\n\n\n\n<p>For deeper context on inbox placement and domain reputation, the <a href=\"https:\/\/photonconsole.com\/blog\/improve-email-deliverability\/\" target=\"_blank\" rel=\"noreferrer noopener\">email deliverability guide<\/a> covers both technical and reputational factors. You can also check your domain&#8217;s current authentication health using <a href=\"https:\/\/toolbox.googleapps.com\/apps\/checkmx\/\" target=\"_blank\" rel=\"noreferrer noopener\">Google&#8217;s MX record checker<\/a>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"pricing\">2. Pricing Model Structure<\/h3>\n\n\n\n<p>Pricing model choice has a larger operational impact at scale than it does during onboarding. The three common models behave very differently under growth:<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><thead><tr><th>Pricing Model<\/th><th>Low Volume<\/th><th>High Volume<\/th><th>Spike Risk<\/th><\/tr><\/thead><tbody><tr><td>Subscription tiers<\/td><td>Predictable<\/td><td>Forced tier upgrades<\/td><td>Overage charges or blocked sends<\/td><\/tr><tr><td>Pay-per-use<\/td><td>Cost-efficient<\/td><td>Linear cost growth<\/td><td>Scales automatically<\/td><\/tr><tr><td>Hybrid<\/td><td>Base fee + usage<\/td><td>Tier-dependent<\/td><td>Unpredictable overages<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p>Model the cost at 3x and 10x your expected volume before signing up. The <a href=\"https:\/\/www.photonconsole.com\/pricing.php\" target=\"_blank\" rel=\"noreferrer noopener\">PhotonConsole pricing page<\/a> shows how pay-as-you-use scales without tier penalties. For a detailed volume benchmark, the <a href=\"https:\/\/photonconsole.com\/blog\/how-to-send-100000-transactional-emails-a-month-without-overpaying\/\" target=\"_blank\" rel=\"noreferrer noopener\">guide to sending 100,000 transactional emails cost-effectively<\/a> compares models in detail.<\/p>\n\n\n\n<p>The pricing model becomes far more important once deliverability stability depends on scaling behavior \u2014 which is when it is too late to switch without risk.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"latency\">3. Delivery Latency<\/h3>\n\n\n\n<p>For OTP codes, password resets, and login verification, latency is a user experience metric. A password reset arriving in 45 seconds is friction. One arriving in 4 minutes is churn.<\/p>\n\n\n\n<p>Average delivery time matters less than worst-case authentication latency. Providers rarely publish P99 numbers proactively \u2014 ask for them explicitly.<\/p>\n\n\n\n<p><strong>Engineering Snapshot:<\/strong><br>Normal: 8-second average OTP delivery<br>Traffic spike (referral campaign, 3x volume): P99 climbs to 7 minutes<br>OTP expiry window: 5 minutes<br>Result: Verification failures for a significant portion of new signups<\/p>\n\n\n\n<p>Evaluate whether the provider maintains dedicated transactional queues separate from marketing sends, how queue depth affects latency under burst conditions, and whether documented rate limits create artificial latency at volume.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"observability\">4. Monitoring and Observability<\/h3>\n\n\n\n<p>This is where most SMTP relay evaluations fail. Developers assess the sending feature set during the trial and ignore the diagnostic layer entirely. Then they hit their first production incident.<\/p>\n\n\n\n<p><strong>An SMTP provider without observability tools turns every incident into guesswork. SMTP dashboards tend to fail at exactly the moment engineers need clarity most.<\/strong><\/p>\n\n\n\n<p>Useful observability includes:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Per-message delivery event logs with timestamps: queued, sent, deferred, bounced, delivered<\/li>\n\n\n\n<li>Bounce classification with SMTP response codes \u2014 not just bounce counts<\/li>\n\n\n\n<li>Webhooks for real-time event streaming to your application<\/li>\n\n\n\n<li>Latency metrics broken down by recipient domain<\/li>\n\n\n\n<li>Suppression list management with removal audit trails<\/li>\n<\/ul>\n\n\n\n<p>Observability matters most when latency problems stop looking like latency problems and start looking like user churn. The <a href=\"https:\/\/photonconsole.com\/blog\/smtp-monitoring-tools-for-transactional-email-infrastructure-an-engineering-guide\/\" target=\"_blank\" rel=\"noreferrer noopener\">engineering guide to SMTP monitoring tools<\/a> covers what each visibility layer catches and when it matters.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"scalability\">5. Scalability Behavior<\/h3>\n\n\n\n<p>Scalability is not about maximum throughput. It is about how the relay behaves when your traffic profile changes suddenly \u2014 and transactional email workloads are inherently bursty.<\/p>\n\n\n\n<p>Product launches, referral campaigns, and scheduled digest sends can produce spikes of 10x to 50x baseline volume. Rate limits and queue behavior under these conditions are what determine whether users experience delays.<\/p>\n\n\n\n<p><strong>Engineering Snapshot:<\/strong><br>Shared IP reputation degrades due to neighbor sender<br>\u2192 Gmail increases throttling on inbound connections from that IP<br>\u2192 Queue retry volume spikes as messages defer<br>\u2192 OTP latency climbs across all senders on the pool<\/p>\n\n\n\n<p>Evaluate: Does excess traffic queue internally or get rejected? How does the provider handle retry storms? Is burst capacity documented anywhere beyond marketing copy? For more on how queue failures compound, see the <a href=\"https:\/\/photonconsole.com\/blog\/emails-delayed\/\" target=\"_blank\" rel=\"noreferrer noopener\">guide to email delivery delays<\/a>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"authentication\">6. Authentication and Security<\/h3>\n\n\n\n<p>Most SMTP errors occur due to misconfiguration or authentication issues. SPF, DKIM, and DMARC alignment is foundational \u2014 not optional. Evaluate whether the provider signs with per-domain DKIM keys (not a shared generic key), provides clear SPF include records, and supports DMARC policy enforcement with reporting integration.<\/p>\n\n\n\n<p>Verify your domain&#8217;s authentication configuration using <a href=\"https:\/\/mxtoolbox.com\/SuperTool.aspx\" target=\"_blank\" rel=\"noreferrer noopener\">MXToolbox SuperTool<\/a>. The <a href=\"https:\/\/photonconsole.com\/blog\/spf-dkim-dmarc-explained-simply\/\" target=\"_blank\" rel=\"noreferrer noopener\">SPF, DKIM, and DMARC guide<\/a> explains how each layer interacts and what failures look like diagnostically.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"developer-experience\">7. API and Developer Experience<\/h3>\n\n\n\n<p>Poor API design has operational consequences: harder debugging, slower incident response, brittle integrations. Evaluate whether:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Error responses are machine-readable with consistent codes<\/li>\n\n\n\n<li>The API distinguishes temporary failures from permanent ones<\/li>\n\n\n\n<li>SDKs surface delivery errors clearly at the call site<\/li>\n\n\n\n<li>Failed sends can be replayed or requeued without manual intervention<\/li>\n<\/ul>\n\n\n\n<p>The <a href=\"https:\/\/photonconsole.com\/blog\/email-api-integration\/\" target=\"_blank\" rel=\"noreferrer noopener\">email API integration guide<\/a> covers integration patterns for common development stacks including Node.js, PHP, and WordPress environments.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"transparency\">8. Operational Transparency<\/h3>\n\n\n\n<p>This silently breaks setups: a team spends hours debugging a deliverability problem while a known infrastructure issue on the provider&#8217;s side goes uncommunicated. Time lost to guesswork that a single status update would have resolved in minutes.<\/p>\n\n\n\n<p>Evaluate whether the provider publishes incident postmortems, whether degraded states are reported proactively or only after user escalations, and how quickly incidents are acknowledged after they begin.<\/p>\n\n\n\n<p><strong>The operational quality of an SMTP relay is easiest to measure during failure, not during uptime. Read the last three incident postmortems before signing a contract.<\/strong><\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"evaluation-mistakes\">Most Common SMTP Relay Evaluation Mistakes<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Choosing Based on Free Tier Alone<\/h3>\n\n\n\n<p>Free tier limits are a customer acquisition mechanism, not an infrastructure benchmark. A provider offering 10,000 free emails may impose aggressive rate limits, offer minimal observability, and enforce restrictive upgrade paths. The operational question is not &#8220;how many emails are free?&#8221; \u2014 it is &#8220;how does this provider behave at 500,000 emails per month?&#8221;<\/p>\n\n\n\n<p><strong>Free tier stability is not a deliverability benchmark. Low-volume success does not predict production reliability.<\/strong><\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Ignoring Observability Until an Incident Forces the Issue<\/h3>\n\n\n\n<p>Delivery logs and bounce diagnostics feel unnecessary right up until the first production failure. At that point, their absence is catastrophic. Evaluate the diagnostic layer during the trial period \u2014 not in response to an incident.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Underestimating Scaling Cost<\/h3>\n\n\n\n<p>Evaluating SMTP cost at current volume is one of the most predictable budget mistakes in SaaS infrastructure. Model 3x and 10x scenarios against the pricing tier structure explicitly before committing. A <a href=\"https:\/\/www.photonconsole.com\/relay.php\" target=\"_blank\" rel=\"noreferrer noopener\">pay-per-use SMTP relay service<\/a> eliminates the tier jump problem entirely by scaling linearly with actual volume.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Mixing Marketing and Transactional Traffic<\/h3>\n\n\n\n<p>Marketing campaigns generate spam complaints that damage IP reputation. If transactional and marketing sends share the same pool, a problematic campaign can delay OTP delivery for all users. Always use separate infrastructure \u2014 or at minimum, separate IP pools. The <a href=\"https:\/\/photonconsole.com\/blog\/transactional-vs-marketing-email\/\" target=\"_blank\" rel=\"noreferrer noopener\">transactional vs marketing email guide<\/a> explains the architectural separation clearly.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Evaluating Average Latency Instead of Tail Latency<\/h3>\n\n\n\n<p>Average delivery time hides the tail behavior that causes authentication failures. Always request P95 and P99 latency data and simulate burst conditions during the trial period. Latency problems become authentication problems faster than teams expect.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Not Testing Deliverability During the Trial<\/h3>\n\n\n\n<p>Use <a href=\"https:\/\/www.mail-tester.com\/\" target=\"_blank\" rel=\"noreferrer noopener\">Mail Tester<\/a> during the trial to score outbound message quality. Send to Gmail, Outlook, and Yahoo test inboxes. Check inbox placement and header authentication before committing \u2014 not after. The <a href=\"https:\/\/photonconsole.com\/blog\/smtp-testing-methods\/\" target=\"_blank\" rel=\"noreferrer noopener\">SMTP testing methods guide<\/a> provides a structured pre-commitment methodology.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"shared-vs-dedicated\">Shared IP vs Dedicated IP: How to Decide<\/h2>\n\n\n\n<p>The distinction matters less than the conditions that make each model appropriate for your sending profile.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><thead><tr><th>Factor<\/th><th>Shared IP<\/th><th>Dedicated IP<\/th><\/tr><\/thead><tbody><tr><td>Initial reputation<\/td><td>Inherited from pool<\/td><td>Must be built from zero<\/td><\/tr><tr><td>Reputation isolation<\/td><td>None \u2014 neighbor risk exists<\/td><td>Full isolation<\/td><\/tr><tr><td>Warmup required<\/td><td>No<\/td><td>Yes \u2014 several weeks minimum<\/td><\/tr><tr><td>Minimum volume needed<\/td><td>Any volume<\/td><td>50,000+ emails\/month consistently<\/td><\/tr><tr><td>Sending consistency required<\/td><td>Not critical<\/td><td>Critical \u2014 gaps cause reputation decay<\/td><\/tr><tr><td>Management overhead<\/td><td>Low<\/td><td>Higher<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p>For most early-stage and mid-volume SaaS products, a well-managed shared IP pool is the operationally correct choice. Dedicated IPs become justified at consistent high volume where reputation isolation outweighs warmup management overhead.<\/p>\n\n\n\n<p>The key qualifier is &#8220;well-managed.&#8221; A shared pool without active hygiene is reputation risk inheritance, not reputation benefit.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"how-to-test\">How to Test an SMTP Relay Before Committing<\/h2>\n\n\n\n<p>Most developers test whether email sends successfully. Few test whether it arrives reliably under stress.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Inbox Placement Testing<\/h3>\n\n\n\n<p>Send test messages to Gmail, Outlook, Yahoo, and Apple Mail. Inspect headers to verify DKIM signatures, SPF alignment, and DMARC policy using <a href=\"https:\/\/www.mail-tester.com\/\" target=\"_blank\" rel=\"noreferrer noopener\">Mail Tester<\/a> or <a href=\"https:\/\/mxtoolbox.com\/EmailHeaders.aspx\" target=\"_blank\" rel=\"noreferrer noopener\">MXToolbox Email Header Analyzer<\/a>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Latency Testing<\/h3>\n\n\n\n<p>Send batches of 100, 1,000, and 10,000 messages and record time-to-delivery at each scale. Watch for non-linear latency degradation \u2014 the clearest signal of queue congestion under volume.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Bounce Handling and Observability Audit<\/h3>\n\n\n\n<p>Send to intentionally invalid addresses. Verify bounce classification, automatic suppression list updates, and SMTP response code detail. Then deliberately trigger a failure scenario and assess whether the dashboard provides enough information to diagnose the problem without contacting support. If it does not \u2014 that is your answer.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Burst Traffic Simulation<\/h3>\n\n\n\n<p>Submit 5,000\u201310,000 messages in a short window. Observe whether traffic queues smoothly, hits rate limits, or gets rejected. This is the most reliable way to understand burst behavior before production depends on it.<\/p>\n\n\n\n<p><strong>Pre-Commitment Evaluation Checklist<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Verify inbox placement across Gmail, Outlook, and Yahoo<\/li>\n\n\n\n<li>Confirm DKIM, SPF, and DMARC pass via header inspection<\/li>\n\n\n\n<li>Test latency at 100, 1,000, and 10,000 message batch sizes<\/li>\n\n\n\n<li>Validate bounce classification and automatic suppression list behavior<\/li>\n\n\n\n<li>Simulate burst traffic and observe rate limit or rejection behavior<\/li>\n\n\n\n<li>Trigger a deliberate failure \u2014 evaluate diagnostic visibility without contacting support<\/li>\n\n\n\n<li>Test webhook delivery reliability and event schema completeness<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"reality-snapshot\">Reality Snapshot: OTP Delivery Failure During a Traffic Spike<\/h2>\n\n\n\n<p>A SaaS authentication platform was running on a mid-tier SMTP relay with shared IP infrastructure. Normal OTP latency averaged under 10 seconds. A referral campaign caused signups to climb 400% over 72 hours \u2014 each new registration triggering an immediate email verification OTP.<\/p>\n\n\n\n<p>What followed:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Shared queue depth increased as burst traffic from multiple senders hit simultaneously.<\/li>\n\n\n\n<li>The platform&#8217;s OTP messages entered a deferred state with no visible queue position or ETA in the dashboard.<\/li>\n\n\n\n<li>OTP delivery latency climbed from under 10 seconds to over 6 minutes during peak hours.<\/li>\n\n\n\n<li>New users encountered expired OTP codes \u2014 the verification window was 5 minutes.<\/li>\n\n\n\n<li>The support team could not distinguish delayed messages from failed ones. The dashboard showed sent counts only.<\/li>\n\n\n\n<li>Engineering escalated to provider support. Response time: over 3 hours. The explanation: &#8220;elevated queue volumes due to platform-wide traffic.&#8221;<\/li>\n\n\n\n<li>The platform manually rate-limited new signups to drain the queue \u2014 throttling its own growth on its best traffic day.<\/li>\n<\/ol>\n\n\n\n<p>The incident lasted approximately 11 hours. Approximately 18% of new signups during the peak period did not complete email verification.<\/p>\n\n\n\n<p>The root cause was not the traffic spike. It was shared queue infrastructure with no transactional priority lanes, no burst capacity documentation, and no observability to diagnose queue state in real time. None of these gaps were visible during the trial period.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"photonconsole\">How PhotonConsole Approaches SMTP Relay Infrastructure<\/h2>\n\n\n\n<p>PhotonConsole&#8217;s infrastructure is designed around the failure modes this framework describes \u2014 not as marketing positioning, but as architectural decisions with specific operational consequences.<\/p>\n\n\n\n<p>Transactional traffic is isolated from lower-priority bulk delivery patterns. Delivery-event visibility is exposed at the per-message level \u2014 queue state, delivery time, bounce classification, and SMTP response codes \u2014 rather than aggregated send counts. This observability layer is accessible through both the dashboard and the API, so delivery diagnostics integrate directly into your operational tooling rather than requiring manual dashboard inspection during incidents.<\/p>\n\n\n\n<p>The pricing model is pay-per-use with no monthly volume commitment. Cost scales linearly with actual sending volume \u2014 eliminating the non-linear tier jumps that create budget surprises at growth inflection points. Authentication setup (DKIM signing, SPF alignment, DMARC policy) is part of the standard onboarding flow, not an advanced configuration add-on.<\/p>\n\n\n\n<p>The <a href=\"https:\/\/www.photonconsole.com\/relay.php\" target=\"_blank\" rel=\"noreferrer noopener\">SMTP relay service<\/a> supports both standard SMTP credentials and API-based sending, making integration straightforward with existing applications, WordPress installations, and custom stacks \u2014 without rebuilding delivery workflows from scratch.<\/p>\n\n\n\n<p>If you are evaluating alternatives to SendGrid, Mailgun, or Amazon SES, the <a href=\"https:\/\/photonconsole.com\/blog\/best-mailgun-alternatives\/\" target=\"_blank\" rel=\"noreferrer noopener\">Mailgun alternatives comparison<\/a> and <a href=\"https:\/\/photonconsole.com\/blog\/sendgrid-vs-mailgun\/\" target=\"_blank\" rel=\"noreferrer noopener\">SendGrid vs Mailgun analysis<\/a> provide structured comparisons across the same criteria framework.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"checklist\">SMTP Relay Evaluation Checklist<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><thead><tr><th>Evaluation Area<\/th><th>Why It Matters<\/th><th>What to Verify<\/th><\/tr><\/thead><tbody><tr><td>Deliverability reliability<\/td><td>Direct impact on inbox placement<\/td><td>Placement rate across Gmail, Outlook, Yahoo; IP hygiene practices<\/td><\/tr><tr><td>Pricing model<\/td><td>Cost predictability at scale<\/td><td>Per-email cost at 3x and 10x volume; overage behavior; tier thresholds<\/td><\/tr><tr><td>Delivery latency<\/td><td>OTP and authentication email UX<\/td><td>P95\/P99 latency; burst behavior; dedicated transactional queue existence<\/td><\/tr><tr><td>Monitoring and observability<\/td><td>Incident diagnosis speed<\/td><td>Per-message event logs; bounce classification with response codes; webhook reliability<\/td><\/tr><tr><td>Authentication support<\/td><td>Deliverability and domain reputation<\/td><td>Per-domain DKIM signing; SPF alignment; DMARC policy enforcement<\/td><\/tr><tr><td>Scalability behavior<\/td><td>Burst traffic handling<\/td><td>Rate limit documentation; queue behavior under load; retry storm handling<\/td><\/tr><tr><td>Bounce handling<\/td><td>List hygiene and sender reputation<\/td><td>Hard\/soft classification; automatic suppression; suppression list portability<\/td><\/tr><tr><td>Operational transparency<\/td><td>Incident response speed<\/td><td>Status page quality; proactive incident communication; postmortem publication<\/td><\/tr><tr><td>Developer experience<\/td><td>Integration and debugging quality<\/td><td>Error response clarity; SDK delivery error visibility; documentation accuracy<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<p><strong>Signs You Are Evaluating the Wrong Provider<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>The dashboard shows sent counts but no per-message delivery events<\/li>\n\n\n\n<li>Bounce data is aggregated without SMTP response code detail<\/li>\n\n\n\n<li>There is no public status page, or it shows only historical uptime percentages<\/li>\n\n\n\n<li>Per-email cost at 100,000+ volume is unclear or absent from documentation<\/li>\n\n\n\n<li>Transactional and marketing sends share the same IP pool with no separation option<\/li>\n\n\n\n<li>DKIM setup requires manual key management without dashboard-level validation<\/li>\n\n\n\n<li>Burst traffic behavior is undocumented or described only in marketing language<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">Pro Tips for Choosing an SMTP Relay<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Test during business hours in your target region.<\/strong> Off-peak trial performance does not reflect behavior when your peak sending coincides with peak receiving load at major ISPs.<\/li>\n\n\n\n<li><strong>Check suppression list portability before committing.<\/strong> Some providers do not allow export. Migration then means re-accumulating hard bounce and unsubscribe data from scratch \u2014 a significant deliverability setback.<\/li>\n\n\n\n<li><strong>Verify how your sending is classified.<\/strong> Some providers classify bulk transactional sends (digest emails, system notifications) as marketing traffic, applying different rate limits or pricing. Confirm the classification before deployment.<\/li>\n\n\n\n<li><strong>Read the last three incident postmortems.<\/strong> Postmortem quality is the clearest available signal of how much engineering visibility you will have during a production failure.<\/li>\n\n\n\n<li><strong>Map volume growth against tier thresholds.<\/strong> Identify the exact monthly volume at which you cross into the next pricing tier. Many providers have non-linear cost jumps at specific thresholds that are not obvious from the pricing page.<\/li>\n<\/ul>\n\n\n\n<p>For a complete pre-launch infrastructure review, the <a href=\"https:\/\/photonconsole.com\/blog\/email-infrastructure-checklist-for-saas-products-before-launch\/\" target=\"_blank\" rel=\"noreferrer noopener\">email infrastructure checklist for SaaS products<\/a> covers SMTP, authentication, deliverability, and monitoring in a single structured reference.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">Related Issues<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><a href=\"https:\/\/photonconsole.com\/blog\/smtp-not-working\/\" target=\"_blank\" rel=\"noreferrer noopener\">SMTP not working: common causes and fixes<\/a><\/li>\n\n\n\n<li><a href=\"https:\/\/photonconsole.com\/blog\/smtp-authentication-error\/\" target=\"_blank\" rel=\"noreferrer noopener\">SMTP authentication errors: diagnosis and resolution<\/a><\/li>\n\n\n\n<li><a href=\"https:\/\/photonconsole.com\/blog\/emails-sent-but-not-delivered\/\" target=\"_blank\" rel=\"noreferrer noopener\">Emails sent but not delivered: what to check<\/a><\/li>\n\n\n\n<li><a href=\"https:\/\/photonconsole.com\/blog\/smtp-connection-timeout\/\" target=\"_blank\" rel=\"noreferrer noopener\">SMTP connection timeout: causes and fixes<\/a><\/li>\n\n\n\n<li><a href=\"https:\/\/photonconsole.com\/blog\/smtp-response-codes-explained\/\" target=\"_blank\" rel=\"noreferrer noopener\">SMTP response codes explained<\/a><\/li>\n\n\n\n<li><a href=\"https:\/\/photonconsole.com\/blog\/how-to-reduce-email-bounce-rate-for-saas-applications-a-technical-guide\/\" target=\"_blank\" rel=\"noreferrer noopener\">How to reduce email bounce rate for SaaS applications<\/a><\/li>\n\n\n\n<li><a href=\"https:\/\/photonconsole.com\/blog\/why-emails-go-to-spam-in-gmail\/\" target=\"_blank\" rel=\"noreferrer noopener\">Why emails go to spam in Gmail and how to fix it<\/a><\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"faq\">Frequently Asked Questions<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What should I evaluate when choosing an SMTP relay?<\/h3>\n\n\n\n<p>Evaluate deliverability reliability, P95\/P99 latency (not just averages), observability tooling, pricing at 3x\u201310x volume, authentication support, burst traffic behavior, and operational transparency. Free tier performance is not a reliable signal of production quality.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">What is an SMTP relay?<\/h3>\n\n\n\n<p>An SMTP relay is infrastructure that accepts outbound email from your application, manages queuing and retries, communicates with recipient ISPs, and tracks delivery outcomes per message. Your application receives a 250 OK acceptance \u2014 actual delivery happens asynchronously.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">What is the difference between an SMTP relay and an email API?<\/h3>\n\n\n\n<p>An SMTP relay accepts messages via the standard SMTP protocol with no code changes needed for existing integrations. An email API accepts messages via HTTP with a custom payload. SMTP relay is faster to integrate into existing applications; email APIs offer more programmatic flexibility for new builds.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How do I test SMTP relay deliverability before committing?<\/h3>\n\n\n\n<p>Send to Gmail, Outlook, and Yahoo inboxes and inspect headers for DKIM, SPF, and DMARC pass. Use <a href=\"https:\/\/www.mail-tester.com\/\" target=\"_blank\" rel=\"noreferrer noopener\">Mail Tester<\/a> to score authentication and content quality. Also send to invalid addresses to verify bounce classification and suppression list behavior.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">When do I need a dedicated IP address for email?<\/h3>\n\n\n\n<p>Dedicated IPs are justified at consistent volumes above 50,000\u2013100,000 emails per month. Below that threshold, a well-managed shared IP pool is more cost-effective and requires no warmup management.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How does SMTP relay pricing scale?<\/h3>\n\n\n\n<p>Subscription tiers create non-linear cost jumps at volume thresholds. Pay-per-use scales linearly. Always model per-email cost at 3x and 10x projected volume \u2014 the entry price almost never reflects the production cost.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Why do SMTP relay problems only appear in production?<\/h3>\n\n\n\n<p>Staging environments do not replicate burst behavior, queue congestion, or shared IP reputation effects. Rate limit enforcement and latency degradation under load are only observable at production scale.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">What should I look for in SMTP monitoring?<\/h3>\n\n\n\n<p>Per-message delivery event logs with timestamps, bounce classification with SMTP response codes, webhook delivery for real-time event streaming, and latency metrics by recipient domain. Any of these missing during an incident means extended debugging time.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"key-takeaways\">Key Takeaways<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Deliverability reliability matters more than free-tier volume size<\/li>\n\n\n\n<li>P99 latency matters more than average latency \u2014 especially for OTP and authentication email<\/li>\n\n\n\n<li>Observability quality determines incident recovery speed; evaluate it during the trial, not after go-live<\/li>\n\n\n\n<li>Pricing structure becomes a critical operational factor at 3x\u201310x current volume<\/li>\n\n\n\n<li>Shared IP reputation can degrade transactional reliability \u2014 pool hygiene is not optional<\/li>\n\n\n\n<li>SMTP migration is more expensive than it appears: IP warmup, suppression list portability, and integration re-engineering compound<\/li>\n\n\n\n<li>Choosing an SMTP relay on feature availability alone is how teams end up rebuilding email infrastructure under production pressure<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"conclusion\">Conclusion<\/h2>\n\n\n\n<p>Choosing an SMTP relay is infrastructure architecture, not vendor comparison. The decision affects deliverability, operational cost at scale, incident response capability, and \u2014 for OTP and authentication email \u2014 directly impacts user conversion during the moments that matter most.<\/p>\n\n\n\n<p>Apply this evaluation framework during the trial period. Test deliverability, latency, burst behavior, and observability quality under realistic conditions before your production workload depends on them.<\/p>\n\n\n\n<p>The cheapest SMTP relay during onboarding is rarely the cheapest SMTP relay after production scale begins.<\/p>\n\n\n\n<p>Choose infrastructure you can operate transparently, not infrastructure you hope will perform.<\/p>\n\n\n\n<p>If you are evaluating SMTP relay options for a developer project, startup, or SaaS product, <a href=\"https:\/\/www.photonconsole.com\/\" target=\"_blank\" rel=\"noreferrer noopener\">PhotonConsole<\/a> is built with transactional email as its core focus \u2014 pay-per-use pricing, per-message delivery visibility, and standard authentication without enterprise-tier complexity.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">Recommended Infrastructure Guides<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><a href=\"https:\/\/photonconsole.com\/blog\/smtp-relay-for-transactional-emails\/\" target=\"_blank\" rel=\"noreferrer noopener\">SMTP relay for transactional emails: architecture and setup<\/a><\/li>\n\n\n\n<li><a href=\"https:\/\/photonconsole.com\/blog\/email-infrastructure-fails\/\" target=\"_blank\" rel=\"noreferrer noopener\">Email infrastructure failures: causes and prevention<\/a><\/li>\n\n\n\n<li><a href=\"https:\/\/photonconsole.com\/blog\/best-smtp-relay-service\/\" target=\"_blank\" rel=\"noreferrer noopener\">Best SMTP relay services: technical comparison<\/a><\/li>\n\n\n\n<li><a href=\"https:\/\/photonconsole.com\/blog\/transactional-email-service\/\" target=\"_blank\" rel=\"noreferrer noopener\">Transactional email service: what to look for at scale<\/a><\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"<p>Choosing an SMTP relay is an infrastructure decision, not a feature checklist. This developer-focused evaluation framework explains how to compare SMTP relays using deliverability reliability, P99 latency, observability, pricing scalability, burst traffic behavior, and operational transparency before production scale exposes hidden failures.<\/p>\n","protected":false},"author":1,"featured_media":212,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[31],"tags":[184,182,187,159,188,110,183,186,155,185],"class_list":["post-211","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-smpt-relay-service","tag-best-smtp-relay-for-developers","tag-choosing-an-smtp-relay","tag-email-infrastructure-evaluation","tag-scalable-smtp-relay","tag-smtp-deliverability","tag-smtp-relay-comparison","tag-smtp-relay-evaluation-framework","tag-smtp-relay-for-saas","tag-smtp-relay-pricing","tag-transactional-email-relay"],"_links":{"self":[{"href":"https:\/\/photonconsole.com\/blog\/wp-json\/wp\/v2\/posts\/211","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/photonconsole.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/photonconsole.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/photonconsole.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/photonconsole.com\/blog\/wp-json\/wp\/v2\/comments?post=211"}],"version-history":[{"count":1,"href":"https:\/\/photonconsole.com\/blog\/wp-json\/wp\/v2\/posts\/211\/revisions"}],"predecessor-version":[{"id":213,"href":"https:\/\/photonconsole.com\/blog\/wp-json\/wp\/v2\/posts\/211\/revisions\/213"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/photonconsole.com\/blog\/wp-json\/wp\/v2\/media\/212"}],"wp:attachment":[{"href":"https:\/\/photonconsole.com\/blog\/wp-json\/wp\/v2\/media?parent=211"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/photonconsole.com\/blog\/wp-json\/wp\/v2\/categories?post=211"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/photonconsole.com\/blog\/wp-json\/wp\/v2\/tags?post=211"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}