{"id":19145,"date":"2026-04-18T08:33:38","date_gmt":"2026-04-18T06:33:38","guid":{"rendered":"https:\/\/webhosting.de\/blog-greylisting-vs-whitelisting-mailserver-strategien-filtertech\/"},"modified":"2026-04-18T08:33:38","modified_gmt":"2026-04-18T06:33:38","slug":"blog-greylisting-vs-whitelisting-mailserver-strategies-filtertech","status":"publish","type":"post","link":"https:\/\/webhosting.de\/en\/blog-greylisting-vs-whitelisting-mailserver-strategien-filtertech\/","title":{"rendered":"Greylisting vs whitelisting: The best strategies for mail servers"},"content":{"rendered":"<p>Greylisting Whitelisting helps me to target mail server strategies so that spam falls off and legitimate messages land without detours. I show clear steps on how to use greylisting for large spam loads and how to use whitelisting for sensitive senders, supported by <strong>email<\/strong> filtering hosting and supplementary authentication.<\/p>\n\n<h2>Key points<\/h2>\n<p>The following key statements provide a quick overview and set the framework for concrete steps.<\/p>\n<ul>\n  <li><strong>Greylisting<\/strong>: Delays first delivery, filters bots heavily<\/li>\n  <li><strong>Whitelisting<\/strong>: Allows only defined sources, maximum control<\/li>\n  <li><strong>Combination<\/strong>First greylisting, then whitelisting for VIPs<\/li>\n  <li><strong>Authentication<\/strong>SPF, DKIM, DMARC and rDNS<\/li>\n  <li><strong>Monitoring<\/strong>Logs, delivery rate, delays<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/04\/mailserver-strategien-4729.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Greylisting explained briefly: Behavior beats volume<\/h2>\n\n<p>I rely on <strong>Greylisting<\/strong>, because it exploits the SMTP behavior: Unknown senders first receive a temporary 4xx error, such as \u201e451 Temporary Failure\u201c. On the server side, an automatic retry follows after a few minutes, which real mail servers perform correctly. Spam bots often abort because they are trimmed for speed and mass and rarely deliver again. In practice, this technique significantly reduces the volume of spam and noticeably relieves the systems. I always combine greylisting with authentication so that good mails arrive without friction after the first contact and <strong>Spam<\/strong> can't get a foot in the door.<\/p>\n\n<h2>Whitelisting clearly delineated: Control with effort<\/h2>\n\n<p>At <strong>Whitelisting<\/strong> I define permitted senders, domains or IPs and consistently block everything else. This method is suitable for critical communication channels, such as payment providers, internal systems or important partners. The downside is the maintenance effort, as new contacts need an entry before their emails can get through. I therefore structure whitelists according to function and risk, not gut feeling. In this way, I keep the list lean, avoid gaps and ensure <strong>Phishing<\/strong>-path points without losing new contacts unnecessarily.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/04\/mailserver_strategien_meeting_7894.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Greylisting vs. whitelisting: comparison in compact key figures<\/h2>\n\n<p>When making the decision, I look at the effect, effort, delay and risks of both methods. The following table summarizes key points and shows when I use which tool first. I use the strengths of both sides and balance out the weaknesses in a targeted manner. This results in a set-up that hits spam hard and routes legitimate senders through quickly. A clear view of these <strong>Key figures<\/strong> accelerates the choice in projects.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Aspect<\/th>\n      <th>Greylisting<\/th>\n      <th>Whitelisting<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Approach<\/td>\n      <td>Temporary rejection of new sender (4xx), please try again<\/td>\n      <td>Only explicitly permitted senders\/domains\/IPs pass through<\/td>\n    <\/tr>\n    <tr>\n      <td>Spam reduction<\/td>\n      <td>Very high due to bot filtering on first contact<\/td>\n      <td>Very high due to strict pre-release<\/td>\n    <\/tr>\n    <tr>\n      <td>Expenditure<\/td>\n      <td>Low in operation, low maintenance<\/td>\n      <td>Medium to high due to list maintenance<\/td>\n    <\/tr>\n    <tr>\n      <td>Delay<\/td>\n      <td>First mail: usually 5-15 minutes<\/td>\n      <td>No delay for released channels<\/td>\n    <\/tr>\n    <tr>\n      <td>Flexibility<\/td>\n      <td>High adaptation to delivery behavior<\/td>\n      <td>Limited to maintained entries<\/td>\n    <\/tr>\n    <tr>\n      <td>Best use<\/td>\n      <td>General spam protection for high volumes<\/td>\n      <td>Critical paths with zero tolerance<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Hybrid setup: Rough filtering, targeted activation<\/h2>\n\n<p>I put greylisting at the top of the list and let suspicious initial contacts wait until real server behavior becomes apparent. After that, I use a well-maintained whitelist to target process-critical senders so that ticketing, payment flows or SSO emails run without delay. I also block known offenders with a blacklist and add a precise evaluation using spam scoring. This combination provides me with strong <strong>Spam<\/strong> protection and keeps collateral damage to a minimum. If you need a deeper starting point, you can find a good introduction to greylisting in the hosting context here: <a href=\"https:\/\/webhosting.de\/en\/greylisting-mailserver-spam-protection-hosting-serverboost\/\">Use greylisting in hosting<\/a>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/04\/email-strategies-grey-whitelist-4582.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Configuration in Postfix or Exim: Practical approach<\/h2>\n\n<p>I like to start with a greylisting service like Postgrey in Postfix and place it early in the SMTP checks. The triplet cache of sender IP, sender address and recipient address ensures that repetitions run through without a new stop. I define separate files or policies for whitelists so that I can version and audit entries cleanly. This works similarly in Exim: ACLs first check authentication and greylisting, then whitelist rules take effect. So the <strong>Pipeline<\/strong> clearly legible and errors show up immediately in the logs.<\/p>\n\n<p>In Postfix, I prefer to place the policy query in smtpd_recipient_restrictions or smtpd_client_restrictions so that the decision is made early. For Postgrey, useful start values are e.g. 300-600 seconds delay, an auto-whitelist interval of 30 days and a persistent cache that survives restarts. I separate whitelist sources by type: IP networks (e.g. payment providers), domains with a stable SPF\/DKIM setup (e.g. SSO providers) and internal systems. In Exim, I structure the ACLs in such a way that I first evaluate authentication results (SPF, DKIM, DMARC), then apply greylisting and only then check a whitelist exception. This sequence avoids detours and reduces wrong decisions.<\/p>\n\n<h2>Authentication: SPF, DKIM, DMARC and rDNS as mandatory programs<\/h2>\n\n<p>I do not rely solely on filters, but also technically secure the identity and delivery route. SPF determines which hosts are allowed to send, DKIM signs content, and DMARC links both with clear policies. Reverse DNS (PTR) visibly links IP and host name, which strengthens reputation and allows filters to work more cleanly. If you set your rDNS cleanly, you will receive noticeably fewer rejections from third-party servers. A step-by-step explanation of PTR and co. will help you get started: <a href=\"https:\/\/webhosting.de\/en\/reverse-dns-ptr-records-mail-hosting-authentication-mailbox\/\">Set rDNS and PTR correctly<\/a> for better <strong>Deliverability<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/04\/mailserver_strategien_6521.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Minimize delays: Fine-tune greylisting<\/h2>\n\n<p>I choose a waiting time that is not too long, often 5 to 10 minutes, and thus protect time-critical processes. I add VIP senders directly to the whitelist so that password resets and order confirmations arrive without a pause. For services with changing IPs, I use domain-based rules and check SPF alignment to accept legitimate rotation. Logs show me which senders repeatedly get stuck and I adjust rules without hesitation. This keeps the <strong>Latency<\/strong> small and protection remains high.<\/p>\n\n<p>Another lever is the cache strategy: the first hit is placed in an auto-whitelist with a defined validity (e.g. 30-90 days). Successful repeat deliveries extend this period. For newsletters and large SaaS senders, I sometimes accept a broader triplet matching (e.g. aggregate subnets) if the sender IP changes frequently but the authentication is stable. Important: I document exceptions and re-evaluate them regularly so that temporary simplifications do not become permanent loopholes.<\/p>\n\n<h2>Maintain whitelists efficiently: Automation and clean processes<\/h2>\n\n<p>I keep manual intervention to a minimum and prefer to feed whitelist entries via API or from the CRM. New business partners first end up in a temporary approval and then move to the permanent list after a short period of observation. I regularly remove departures so that the hit list remains lean and there is no uncontrolled growth. For admins who already use spam filters, it is worth taking a look at these instructions: <a href=\"https:\/\/webhosting.de\/en\/all-incl-spam-filter-configuration-protection\/\">Configure spam filters wisely<\/a> and whitelist rules neatly integrated. A clear <strong>Policy<\/strong> per sender group avoids random decisions.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/04\/mailserver_strategien_7483.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Monitoring and metrics: Figures that I check daily<\/h2>\n\n<p>I look at the delivery rate, first contact delay, bounce rates and spam throughput. Conspicuous patterns in the logs often indicate incorrectly set rules or faulty DNS entries. I roll out changes gradually and compare key figures before and after the adjustment. A clear weekly report keeps the team informed and shortens the response time in the event of problems. This <strong>Metrics<\/strong> ensure operation and prevent blind spots.<\/p>\n\n<p>I also monitor the proportion of greylist-related defers, average retry time until delivery, size and age of the deferred queue, proportion of auto-whitelist hits and top senders after failed attempts. I set practical alarm limits: if the deferred queue increases unexpectedly or the proportion of successful retries falls, there is often a network fault or the rule is too hard. I separate internal from external key figures so that I can quickly assign causes.<\/p>\n\n<h2>Avoid stumbling blocks: What I notice in projects<\/h2>\n\n<p>Rotating sender IPs without SPF coverage often cause unnecessary waiting times with greylisting. I therefore check sender profiles carefully and only make exceptions where the benefit is clear. Overloaded whitelists quickly become a gateway, which is why I consistently clean them up. Missing rDNS entries trigger rejections even though the sender is legitimate, which I discover early on with a DNS check. With clear <strong>Rules<\/strong> these traps disappear step by step.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/04\/mailserver-strategien-7685.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Borderline cases and forwarding: Distributors, SRS and ARC<\/h2>\n<p>Redirects and distributors are special cases: SPF often breaks after the jump, DMARC fails and this can influence greylisting decisions. I therefore check the authentication chain: If the forwarding server sets SRS (Sender Rewriting Scheme), SPF and Envelope From are correct again. Alternatively, a stable DKIM signature from the original sender, which remains unchanged during forwarding, helps. ARC headers document the verification steps along the chain and provide me with additional signals so as not to slow down legitimate forwarding unnecessarily. For known forwarding services, I keep a separate, strictly checked whitelist that only takes effect if DKIM\/ARC is plausible.<\/p>\n\n<h2>Handling cloud senders and dynamic IP pools correctly<\/h2>\n<p>Large platforms (e.g. office and newsletter services) use broad and changing IP pools. I rely less on individual IPs here and more on a bundle of features: valid SPF alignment, stable DKIM domain, consistent HELO\/EHLO behavior and clean rDNS. Greylisting remains active, but I accept faster activations as soon as the set of signals is consistent. For transactional mails from such services, I link whitelist rules with header characteristics (e.g. return path, list id or specific DKIM-d=) to prevent abuse by simple from-spoofs.<\/p>\n\n<h2>Scaling and high availability: sharing caches intelligently<\/h2>\n<p>If I operate several MX servers, I share the greylisting cache centrally (e.g. via database or in-memory store) so that an initial contact on MX1 does not lead to unnecessary waiting times on MX2. Consistent hashing strategies prevent hotspots, and a short but resilient TTL per triplet ensures a good balance between protection and speed. During maintenance or failover, I make sure that the cache is preserved so as not to produce a spike in initial delays after restarts. I also separate statistics per node and aggregate them centrally so that bottlenecks in the cluster become visible.<\/p>\n\n<h2>Advanced practice in Postfix and Exim<\/h2>\n<p>In Postfix, I like to use light tarpitting (short greet delays) to expose rogue clients without burdening legitimate senders. I prioritize TLS handshakes and authentication checks over deeper content scans so that the resource consumption remains calculable. In Exim, I consistently use the order of ACLs: first HELO\/client checks, then SPF\/DKIM\/DMARC, then greylisting, finally whitelist\/blacklist and RBL\/scoring. For error analyses, I mark decisions with specific X headers (e.g. X-Policy-Decision) so that delivery paths can be clearly traced later.<\/p>\n\n<h2>Reduce spoofing risks in whitelists<\/h2>\n<p>I do not release blanket from-domains. Instead, I combine criteria: Sender IP or trusted network, matching SPF\/DKIM result, optional TLS certificate features. Where only domains can be maintained, I require DMARC alignment to prevent spoofing using simple envelope tricks. For particularly sensitive channels, I document the reason for approval, an owner of the rule and an expiration date. If an exception expires, I consciously make a new decision - so whitelists remain a tool, not a risk.<\/p>\n\n<h2>Compliance, data protection and audits<\/h2>\n<p>Logs contain personal data (IPs, addresses). I therefore define retention periods, masking rules and access levels. Audit trails for every whitelist change (who, when, why) help in an emergency and reduce misconfigurations. For multi-tenant setups, I separate policies and data per client, preventing exceptions from having an unintended global effect. Clear processes - from the application form to dual control approval - make maintenance audit-proof and still speed up operations.<\/p>\n\n<h2>Rollout strategy and tests<\/h2>\n<p>I first test new rules in an observation mode: Greylisting logs, but does not yet reject, so that I see effects without risk. This is followed by stages: Pilot domains, selected departments, finally global. I plan rollouts outside critical time windows, have a fallback plan ready and communicate changes early. Test emails from representative sources (transactions, newsletters, partners, private mailboxes) are a good reflection of reality. Only when the figures and feedback are right do I finally go live.<\/p>\n\n<h2>Recognize error patterns faster: typical log patterns<\/h2>\n<p>Repeated 4xx without a subsequent delivery attempt indicate bots or incorrectly configured senders. 5xx after a successful retry are more likely to indicate content or policy problems. If you see many initial contacts from the same network, but without a valid rDNS, a network fault or an aggressive bot should be suspected. If defers accumulate on a handful of legitimate domains, I check SPF\/DKIM\/DMARC and whether my exception rules still apply. A dedicated daily report with the top 10 sources of problems speeds up reactions considerably.<\/p>\n\n<h2>Operational playbooks and emergency paths<\/h2>\n<p>I have clear playbooks ready: What happens if a critical partner suddenly gets stuck? A temporary bypass with limited validity, documented and limited in time, gets operations up and running while the cause is analyzed. I then roll back the exception and make specific adjustments to the rules. I define short checklists for on-call teams: status of DNS, rDNS, queue, policy services and authentication checks - this keeps response times to a minimum.<\/p>\n\n<h2>Briefly summarized: My recommendation based on volume and risk<\/h2>\n\n<p>If the volume of spam is high, I start with <strong>Greylisting<\/strong> as a basic noise filter and place whitelists for critical channels on top. Small setups with a small number of fixed partners quickly perform very well with consistent whitelisting. In mixed environments, a hybrid approach provides the best balance of security, speed and maintenance effort. SPF, DKIM, DMARC and rDNS form the technical framework to ensure that filter rules work reliably and reputation grows. Those who couple these components properly achieve strong <strong>spam<\/strong> protection without frictional losses.<\/p>","protected":false},"excerpt":{"rendered":"<p>**Greylisting vs Whitelisting** - best **spam protection** for **email filtering hosting**. Advantages, comparison and tips for mail servers.<\/p>","protected":false},"author":1,"featured_media":19138,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[821],"tags":[],"class_list":["post-19145","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-spambekaempfung-web_hosting"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"121","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"Greylisting Whitelisting","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"19138","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/19145","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/comments?post=19145"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/19145\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media\/19138"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media?parent=19145"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/categories?post=19145"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/tags?post=19145"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}