{"id":19017,"date":"2026-04-14T08:35:56","date_gmt":"2026-04-14T06:35:56","guid":{"rendered":"https:\/\/webhosting.de\/dkim-key-rotation-verwaltung-server-sicherheit-rotationsplan\/"},"modified":"2026-04-14T08:35:56","modified_gmt":"2026-04-14T06:35:56","slug":"dkim-key-rotation-management-server-security-rotation-plan","status":"publish","type":"post","link":"https:\/\/webhosting.de\/en\/dkim-key-rotation-verwaltung-server-sicherheit-rotationsplan\/","title":{"rendered":"DKIM Key Rotation: Mail server management for maximum security"},"content":{"rendered":"<p>The <strong>DKIM Key Rotation<\/strong> keeps mail server keys up to date and protects signed messages from forgery by regularly activating new selectors and safely phasing out old ones. This is how I strengthen <strong>Deliverability<\/strong> and domain reputation, prevent attacks on weak 1024-bit keys and secure mail authentication with 2048-bit keys.<\/p>\n\n<h2>Key points<\/h2>\n\n<ul>\n  <li><strong>2048-bit<\/strong> Replace key as standard, 1024-bit<\/li>\n  <li><strong>Selectors<\/strong> Use in parallel (e.g. selector1\/selector2)<\/li>\n  <li><strong>Intervals<\/strong> 3-12 months, with transition phase<\/li>\n  <li><strong>Tests<\/strong> before switching off the old key<\/li>\n  <li><strong>DMARC<\/strong> monitor, evaluate reports<\/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-sicherheit-8921.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>What the DKIM Key Rotation actually does<\/h2>\n\n<p>I sign outgoing e-mails with a private <strong>key<\/strong>, and recipients check the signature via the public key in the DNS TXT record. Selectors such as selector1._domainkey.example.com reliably link the signature to the matching entry and allow parallel <strong>Keys<\/strong> for smooth changes. Without rotation, keys become obsolete, spam filters penalize short lengths and attackers benefit from longer exposed keys. <strong>Secrets<\/strong>. With a scheduled rotation, I only remove old entries when there are no more validated messages circulating and all systems have the new <strong>Selector<\/strong> use. In this way, I prevent outages and keep the cryptography of my domain up to date. <strong>Level<\/strong>.<\/p>\n\n<h2>Why regular rotation ensures deliverability<\/h2>\n\n<p>Short or old keys cost <strong>Reputation<\/strong>, which is immediately reflected in higher spam rates. I routinely switch to 2048-bit and make sure that providers such as Gmail and Outlook recognize the signature as <strong>trustworthy<\/strong> categorize. Each rotation reduces the attack surface, because compromised or weak keys cannot be used. <strong>opportunity<\/strong> to remain active for longer. I deliberately keep the transition period long enough for caches to expire and for distributed systems to receive new DNS content. <strong>See<\/strong>. For a holistic view of authentication, I recommend the compact <a href=\"https:\/\/webhosting.de\/en\/spf-dkim-dmarc-bimi-explains-optimal-email-security-matrix\/\">E-mail security matrix<\/a>, DKIM with SPF, DMARC and BIMI makes sense. <strong>connects<\/strong>.<\/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_dkim_rotation_8453.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Recommended intervals and key strengths<\/h2>\n\n<p>I rotate every three to twelve months, depending on the risk. <strong>months<\/strong>, more frequently with higher requirements. 2048-bit is my <strong>Standard<\/strong>, because common mail providers evaluate short keys negatively and can block them in the long term. Before switching, I activate a second selector, test signatures and leave the old key active for at least 30 days. <strong>days<\/strong> exist in parallel. During the transition phase, I monitor DMARC report results to identify failures per <strong>Source<\/strong> can be recognized. Only after continuous green checks do I mark the old public key as invalid and clear the DNS value using p=<strong>none<\/strong> or remove.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Risk profile<\/th>\n      <th>Interval<\/th>\n      <th>Key strength<\/th>\n      <th>Transition period<\/th>\n      <th>Monitoring<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Low<\/td>\n      <td>9-12 months<\/td>\n      <td>2048-bit<\/td>\n      <td>30 days<\/td>\n      <td>DMARC reports, delivery rates<\/td>\n    <\/tr>\n    <tr>\n      <td>Medium<\/td>\n      <td>6-9 months<\/td>\n      <td>2048-bit<\/td>\n      <td>30-45 days<\/td>\n      <td>Error rates per selector<\/td>\n    <\/tr>\n    <tr>\n      <td>High<\/td>\n      <td>3-6 months<\/td>\n      <td>2048-bit<\/td>\n      <td>45 days<\/td>\n      <td>Fine-grained policy evaluation<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Technical depth: Setting the DKIM record and signature parameters correctly<\/h2>\n\n<p>For robust signatures, I pay attention to clean parameters in the DNS record and in the signature line in the header. In the DNS record, I set at least v=DKIM1; k=rsa; p=... and leave out unnecessary additions. The <strong>t=<\/strong>-I use the switch specifically: <strong>t=y<\/strong> marks tests (only useful temporarily), <strong>t=s<\/strong> enforces strict use only for the exact d=domain - I only set this if subdomains never sign using the same key. The specification <strong>s=email<\/strong> is optional, as e-mail is the default service anyway. In the signature I define <strong>a=rsa-sha256<\/strong> as an algorithm, <strong>c=relaxed\/relaxed<\/strong> for robust canonicalization, and I <strong>oversign<\/strong> (h=...) critical headers such as From, To, Subject, Date, Message-ID, MIME-Version and Content-Type. On the tags <strong>l=<\/strong> (body length) and <strong>z=<\/strong> (header copy) because they make verification more fragile or reduce privacy.<\/p>\n\n<p>I plan the d=domain so that it matches my DMARC alignment. Where several systems are sending, I deliberately choose subdomains (e.g. crm.example.com) and create my own selectors for each <strong>Use Case<\/strong>. When in doubt, I leave the i= identity in the signature empty so that it automatically matches the d= domain and DMARC does not have to <strong>breaks<\/strong>.<\/p>\n\n<h2>DNS entities: TTL, chunking and provider limits<\/h2>\n\n<p>2048-bit keys are long. Many DNS providers require <strong>Chunking<\/strong> into several partial strings set in quotation marks, which they assemble at runtime. After saving, I check that there are no line breaks or spaces in the Base64 block in the TXT record. I also respect the 255-character rule per string and the overall DNS limits. For quick conversions, I reduce the <strong>TTL<\/strong> a few days before the rotation (e.g. to 300-600 seconds) and increase it again after successful migration. In doing so, I take into account <strong>negative caching<\/strong> (NXDOMAIN), which can delay the perception of premature requests for new selectors.<\/p>\n\n<p>Because not all resolvers update at the same speed, I plan buffers. I keep the old records for at least 30 days, or even longer if the mail volume is very high or the MTAs are slow <strong>45 days<\/strong>. Only then do I delete them or set the public key tag <strong>p=<\/strong> blank to revoke the use. Important: The <strong>p=<\/strong> in the DKIM record describes the public key; the DMARC-<strong>p=<\/strong> controls the policy (none\/quarantine\/reject). I document this <strong>Terminology<\/strong>, so that the team does not mix up terms in Runbooks.<\/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\/dkim-key-rotation-mailserver-2764.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Practical guide: Manual rotation on your own mail server<\/h2>\n\n<p>I start with a new key pair and set 2048 bits as the clear <strong>Line<\/strong>. For OpenDKIM I generate a pair per selector with opendkim-genkey, publish the public key in the DNS and maintain the <strong>Propagation<\/strong> off. I then change the Milter configuration of the MTA to the new selector and check the header signature in test mails. <strong>exactly<\/strong>. If everything fits, I leave both selectors active for the planned transition period so that no legitimate mail is sent to old caches. <strong>fails<\/strong>. Those who use Plesk will find pragmatic tips in the compact <a href=\"https:\/\/webhosting.de\/en\/spf-dkim-dmarc-plesk-guide-safety-tuning-professional\/\">Plesk-Guide<\/a>, that makes DKIM handling and fine-tuning tangible <strong>makes<\/strong>.<\/p>\n\n<p>I document every change in a simple rotation log with date, selector, key size and DNS status as a living <strong>Routine<\/strong>. This journal helps me later during audits, disruptions or team handovers without long <strong>Search<\/strong>. For more convenience, I write a small script that generates keys, formats DNS records and adjusts the MTA config before sending validation mails. <strong>dispatched<\/strong>. In this way, I standardize processes and reduce typing errors that cause expensive downtimes in productive environments. <strong>cause<\/strong>. After the transition period has expired, I revoke old keys in the DNS and check the DMARC reports one last time for <strong>Anomalies<\/strong>.<\/p>\n\n<h2>Secure key management and operational quality<\/h2>\n\n<p>I treat private DKIM keys like others <strong>Secrets<\/strong>Restrictive file permissions (e.g. only readable by the Milter user), no unencrypted backups and clear roles for access and sharing. In larger environments I store keys in <strong>HSM<\/strong>- or secret management systems and only allow MTAs to be signed via defined interfaces. In CI\/CD setups, I keep the keys separate from source code repositories and avoid them being stored in artifacts or logs. <strong>land<\/strong>. A rotating calendar with reminders (e.g. 60\/30\/7 days before the deadline) prevents the renewal from becoming part of everyday business. <strong>perishes<\/strong>.<\/p>\n\n<p>I consciously choose <strong>rsa-sha256<\/strong>; Alternatives such as ed25519-sha256 are efficient, but are not yet widely established in the email ecosystem. 3072-bit RSA increases security, but can reach its limits with some DNS providers. 2048-bit is the robust <strong>Sweet spot<\/strong> from security and compatibility.<\/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_Management_Sicherheit_7834.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Automated rotation with Microsoft 365 and Google Workspace<\/h2>\n\n<p>In Microsoft 365 I use PowerShell and use Rotate-DkimSigningConfig to set the <strong>Soft<\/strong> to a new key, while two selectors are available for a smooth changeover. Microsoft is internally planning a changeover phase lasting several days so that no signed message is lost in transit. <strong>expires<\/strong>. I check DMARC rates and headers during this time until both selectors are clean. <strong>check<\/strong>. In Google Workspace, I generate new selectors manually, enter the public key and set the system to the fresh <strong>Signature<\/strong>. The same applies here: Run in parallel long enough, read logs and only then old keys <strong>switch off<\/strong>.<\/p>\n\n<p>I keep in mind that external platforms have different caching and rollout times, which makes timing and monitoring even more important. <strong>makes<\/strong>. If you serve several transmission channels, consolidate the rotation planning in a calendar with fixed <strong>Windows<\/strong>. This prevents conflicting changes that confuse decoders and receivers and affect delivery rates. <strong>lower<\/strong>. When in doubt, I postpone changeovers to periods with few <strong>Traffic<\/strong>. This also includes clearly communicating maintenance windows and creating test accounts via various target providers. <strong>use<\/strong>.<\/p>\n\n<h2>M365\/Workspace: Special features and pitfalls<\/h2>\n\n<p>I note that Microsoft 365 uses fixed selector names (selector1\/selector2) and internal keys <strong>rolls<\/strong>, as soon as the DNS entries are correct. Depending on the region, emails can be signed with the old or new key in between - the parallel phase is therefore planned. In Google Workspace, I make sure that the TXT key is correct for 2048-bit keys.<strong>Chunking<\/strong> and deliberately set the TTL low for fast visibility. Both platforms log status information; I actively read this to detect timing errors and partial deployments. <strong>to recognize<\/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\/dkim_key_rotation_6734.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Coordinate delegation and multiple ESPs correctly<\/h2>\n\n<p>If service providers work for my domain, I rely on delegation via <strong>CNAME<\/strong>-entries to their _domainkey hosts. This allows providers to keep the key management in their own platform and can manage rotation seamlessly. <strong>steer<\/strong>. I document the selectors used for each source so that I avoid conflicts and no entry is made by mistake. <strong>overwrite<\/strong>. For parallel distribution via newsletter tools, CRM and own gateways, I consciously plan the order of the rotations <strong>through<\/strong>. For each system, I test in advance whether 2048-bit keys are accepted cleanly and headers are consistent. <strong>appear<\/strong>.<\/p>\n\n<p>For fail-safe operation, I define three selectors in advance, but only activate two in regular operation as <strong>Buffer<\/strong>. The third remains in reserve in case I need to use a compromised key immediately. <strong>replace<\/strong> must. This reserve saves deliverability if I need to act at short notice. <strong>must<\/strong>. In addition, I anchor the key management in the internal <strong>Runbook<\/strong> with clear roles. This means that everyone knows who operates DNS, MTA and provider access during a rollout and who is responsible for acceptances. <strong>characterizes<\/strong>.<\/p>\n\n<h2>Clean planning of multi-domain strategy and alignment<\/h2>\n\n<p>I separate productive, transactional and marketing channels logically: Separate subdomains (e.g. billing.example.com, notify.example.com, news.example.com) with separate selectors support clean and transparent marketing channels. <strong>DMARC alignments<\/strong> and reduce side effects in the event of misconfigurations. This means that a CRM dispatch cannot unintentionally damage the reputation of the main domain. <strong>burden<\/strong>. I define owners, rotation dates and test paths for each channel. I avoid multiple systems sharing the same selector and keep the naming <strong>uniform<\/strong> (e.g. s2026q1, s2026q3) so that logs and DMARC reports are immediately understandable.<\/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\/dkim-key-rotation-9056.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Validation and monitoring after the changeover<\/h2>\n\n<p>I verify every changeover with several test mails to various mailboxes, read authentication results and check the DKIM signature down to the last detail. <strong>detail<\/strong>. DMARC aggregate reports provide me with daily pass\/fail ratios for each <strong>Source<\/strong>. I mark conspicuous recipient domains in order to pinpoint routing or DNS problems. <strong>Find<\/strong>. I also log MTA events and correlate them with delivery statistics so that I can quickly identify cause and effect. <strong>recognize<\/strong>. If you still need the basics on SPF, DKIM and DMARC, this compact overview will get you started: <a href=\"https:\/\/webhosting.de\/en\/spf-dkim-dmarc-hosting-email-security-serverauth-server\/\">SPF, DKIM and DMARC<\/a> explain the roles clearly and <strong>concrete<\/strong>.<\/p>\n\n<p>If individual failures persist, I analyze headers for Selector, d=Domain and b=Signature very much <strong>thorough<\/strong>. There is often a typing error in the DNS record, a line break in the public key or an incorrectly set <strong>Hostname<\/strong>. I compare the canonicalization methods used in the signature with the receiver systems to create edge cases with header rewrites. <strong>expose<\/strong>. Then I test again against several mailboxes, because individual providers behave visibly <strong>different<\/strong>. Only when all paths are stable do I finally remove the old key from the <strong>DNS<\/strong>.<\/p>\n\n<h2>Quality metrics and target values<\/h2>\n\n<p>I define internal SLOs for deliverability: DKIM pass rate per source, DMARC alignment per channel, proportion of \u201einbox\u201c deliveries for large providers and time to complete conversion per selector. In the parallel phase, I expect short-term mix rates, but in the medium term a <strong>stable<\/strong> DKIM pass rate close to 100 %. If quotas fall below defined thresholds, I trigger a playbook (rollback, TTL check, DNS validation, MTA config, retests). In this way, I prevent rotations from unnoticedly affecting the <strong>Quality<\/strong> Press.<\/p>\n\n<h2>Common errors and direct solutions<\/h2>\n\n<p>Transition times that are too short break signatures because DNS caches last 24-48 hours. <strong>hold<\/strong>. I therefore plan the parallel phase generously and orient myself to real-life situations. <strong>Running times<\/strong>. 1024-bit keys tear delivery rates, so I rely on 2048-bit as a clear <strong>Default<\/strong>. If the correct selector is missing in the header, I check MTA-Config and OpenDKIM-Map until the sender and DNS are correct. <strong>match<\/strong>. For individual providers with strict limits, I distribute transmission volumes over time in order to minimize suspicions and rate limits. <strong>Avoid<\/strong>.<\/p>\n\n<p>If mails fail despite a clean signature, I look at DMARC policy and SPF alignment as <strong>Chain<\/strong>. Often a CDN, a forwarding service or a CRM connector causes subtle changes to the body or headers that affect DKIM verification. <strong>break<\/strong>. In such cases, I rely on stable canonicalization and check whether an alternative selector with adapted <strong>Policy<\/strong> helps. In addition, I check whether gateways add body rewrites, footers or tracking parameters that I have added to the pipeline. <strong>take into account<\/strong>. Systematic checks save me time in the end and ensure the <strong>Quality<\/strong>.<\/p>\n\n<h2>Emergency plan: Disarm compromised keys immediately<\/h2>\n\n<p>If a key is compromised, I reach for the prepared <strong>Reserve selector<\/strong>: publish new public key, switch MTA to the reserve, select old selector via <strong>p=<\/strong> signal empty or delete. I check whether logs indicate abuse, inform the teams involved and increase the monitoring of DMARC fail rates. I then roll out a fresh third selector on a regular basis in order to <strong>Buffer<\/strong> to be restored. The runbook contains clear roles, communication channels and approval steps to keep response times short. <strong>hold<\/strong>.<\/p>\n\n<h2>Hosting selection: Provider comparison<\/h2>\n\n<p>I pay attention to seamless DKIM support for mail hosting, simple rotation with several <strong>Selectors<\/strong> and 2048-bit standard. Services that only allow 1024-bit jeopardize <strong>Delivery<\/strong> and reputation. Those who integrate OpenDKIM and allow scripting save a lot in practice <strong>Time<\/strong>. In tests, webhoster.de convinces with seamless DKIM integration and automatable <strong>processes<\/strong>. The following overview shows important criteria for the purchase decision clearly and <strong>clear<\/strong>:<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Hosting provider<\/th>\n      <th>DKIM support<\/th>\n      <th>Rotation<\/th>\n      <th>Key strength<\/th>\n      <th>Assessment<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>webhoster.de<\/td>\n      <td>Complete (OpenDKIM)<\/td>\n      <td>Scriptbar &amp; integrated<\/td>\n      <td>2048-bit<\/td>\n      <td><strong>Test winner<\/strong> for admins<\/td>\n    <\/tr>\n    <tr>\n      <td>Other<\/td>\n      <td>Base<\/td>\n      <td>Manual<\/td>\n      <td>Often 1024-bit<\/td>\n      <td>Limited only <strong>suitable<\/strong><\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Compliance, DNSSEC and logging<\/h2>\n\n<p>I activate <strong>DNSSEC<\/strong>, where available, so that the DKIM keys published in the DNS are protected against manipulation. In regulated environments, I define retention periods for logs, DMARC reports and rotation logs. I record who activated, changed or deleted which selector and when. <strong>deactivated<\/strong> has. This traceability is worth its weight in gold in the event of an incident and makes it easier for external <strong>Audits<\/strong>. I also check annually whether policies, intervals and key strengths still match the risk profile.<\/p>\n\n<h2>Integrating rotation into DevOps processes<\/h2>\n\n<p>I integrate the key rotation in CI\/CD so that build pipelines generate keys, fill DNS templates and control MTA configs. <strong>Roll out<\/strong>. Before each production run, a validation stage is carried out that checks DNS visibility and header signature <strong>checks<\/strong>. Rollbacks remain prepared in case a provider imposes unplanned limits or delays. <strong>sets<\/strong>. In addition, I plan an annual security review in which I define intervals, key parameters and reporting quality. <strong>customize<\/strong>. This automation saves time and reduces sources of error at critical points. <strong>Interfaces<\/strong>.<\/p>\n\n<h2>Practical checklist for every rotation<\/h2>\n\n<ul>\n  <li>Create new 2048-bit key, name unique selector (e.g. sYYYYqX)<\/li>\n  <li>Publish DNS TXT record cleanly (check chunking, no line breaks)<\/li>\n  <li>Temporarily reduce TTL, actively monitor propagation<\/li>\n  <li>Change MTA\/ESP to new selector, send test mails to several providers<\/li>\n  <li>Schedule parallel operation (30-45 days), check DMARC reports daily<\/li>\n  <li>Analyze error sources (header, canonicalization, alignment, gateways)<\/li>\n  <li>Revoke\/delete old key only after stable pass rates<\/li>\n  <li>Documentation, runbook and rotation calendar <strong>update<\/strong><\/li>\n<\/ul>\n\n<h2>Practical summary<\/h2>\n\n<p>I secure e-mail channels by using 2048-bit keys, setting clear intervals and only using old keys after they have been cleanly deleted. <strong>Handover<\/strong> remove. Selectors enable a risk-free parallel phase, while DMARC reports ensure the quality of each <strong>Signature<\/strong> make them visible. With structured tests, logging and a checklist, I keep rollouts plannable and <strong>stable<\/strong>. Automation in CI\/CD, delegation to service providers and good hosting with OpenDKIM save noticeably <strong>Expenditure<\/strong>. If you want to delve deeper, you will find compact instructions in the practical <a href=\"https:\/\/webhosting.de\/en\/spf-dkim-dmarc-hosting-email-security-serverauth-server\/\">Guide to SPF, DKIM and DMARC<\/a>, which clearly sets out the most important <strong>names<\/strong>.<\/p>","protected":false},"excerpt":{"rendered":"<p>DKIM Key Rotation optimizes your email security hosting. Learn mail authentication and key management for reliable mails.<\/p>","protected":false},"author":1,"featured_media":19010,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[708],"tags":[],"class_list":["post-19017","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-email"],"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":"523","_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":"DKIM Key Rotation","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":"19010","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/19017","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=19017"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/19017\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media\/19010"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media?parent=19017"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/categories?post=19017"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/tags?post=19017"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}